V03 issue615 - WIS format messages, as proof of concept of using non-sarracenia ones. #698
Conversation
list of candidate directories are accomulated, based on where files are deleted.,. and if they are empty, and have been so for at least one housekeeping interval, then they are deleted, and the parent is primed for consideraation in the future.
…to v03_issue615
petersilva
requested review from
reidsunderland,
tysonkaufmann and
andreleblanc11
|
new issue #699 to addressing missing type field within links field of wis format. |
|
If folks are interested in trying stuff out... I have added a branch to sr3-examples that uses an mqtt broker instead of the rabbitmq one, and publishes wis messages to this broker, and then uses a subscriber to consume them. https://github.com/MetPX/sr3-examples/tree/sr3_issue615/empty-mqtt-pump I think there is sufficient stuf in the branch to close off #615 #617 and #699 |
|
sigh... when I added the "contentType" generation, that added a dependency on a package that one obtains in python using "import magic"... the package is named "python-magic" in pypi (why not plain magic?) and python3-magic in the repos for ubuntu 22.04. but if you go to ubuntu 20.04... it seems around then there were two python packages named python-magic, and one got renamed (they are different packages with different APIs unrelated to each other.) so it seems in older OS's It' hard to figure out what package to have installed. not clear on what to do about this right now. This is causing some tests to sarracenia installs to fail in some of the jobs, which means some of the tests are failing. |
|
summary of discussions at dev meeting:
|
|
yay! it passes now! Someone should merge it now... (preferably squash and merge) |
|
it got merged into main... do you want me to revert it? |
OK, so finally all the pieces are in place to allow support of non-sarracenia messages (talk to external systems). This is about #615, and #617 mostly.
The work is mostly around this file:
postformat/wis.py postformat has two other classes in it, v02.py, and v03.py for the two native sarracenia formats.
In order to demonstrate encapsulation of foreign notification formats, using the wis one as an example.
It is defined here:
So what had to change? The generation of a topic in Sarracenia is structured to be nearly automatic. In other systems, the way the topic field is generated will depend on the network itself, as well as some settings that the user may provide. So that meant that we now need to supply the options (settings) to the postformat encoding class (where it was formerly self-containted.)
Also had to delegate the topic generation to the postformat itself... because it v03.py messages will have a different topic header than wis.py ones, even though both can be sent over MQTT (the same messaging protocol.)
With this branch... someone can subscribe to a sarracenia datapump and post to a WMO pump and vice versa, exchanging messages in the format appropriate for the pump (v03 for Sarracenia, wis for the WMO pump.)