There are certain advantage of using firefly server internal communication. If we are using the server, we would not need to worry about the deployment in the end. Though I am not sure if it is the case that whether we are going to have multiple instances (or machine).
Currently I do not have concrete example of FF should behave like a server. However, I have some primitive thoughts.
-
better information parsing scheme. Currently the information extraction is verbose and redundant. I hope there will be better method we could do for this. For one process to complete, we have to specify the input and output and we have to deal with the filesystem for both the input and output, and also parsing the input and output.
-
state preservation. Each time the process is completely new so that we could not preserve information for the repetitive computation or (if possible) a continuation of series of commands (This is just my pure guess since I am not sure if there is a concrete case. The case I could think about is that if we are looking at the some anomaly of selected region, and we computed some data, and get the results back, the user might want to do some further computation on that data).
However, currently I feel the communication will be verbose and error prone. And since we haven’t settled the use case prototype, I think I might wait until all the needs settled and then move to firefly communication channel.
For this week, I was trying to implement with blinking functionality.
blink <box name> <im1_id> <im2_id> <interval ms> <blink times>
to initialise a blink
It could also do the following
blink <box name> <times> blink more times
And
blink <box name> stop to stop blinking.
The demo is on
http://lsst.cs.illinois.edu/static/index.html