You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the graph dependency is built in the gsn.beans.Modifications class, based on hard-coded wrappers and parameters of those. Adding new communication methods (like zeromq) needs then to modify this.
A workaround was implemented in the virtual sensor loader, by loading files in the lexical order if not contradicting the graph from Modifications.
But to make it explicit, one could add field in the vs xml file and then the dependency graph could be built from that. Of course then the ordering is let to the user, who can then make mistakes...
The virtual sensors loader can also be resilient enough to re-try loading vs that failed until all are launched, independently of the order.
The text was updated successfully, but these errors were encountered:
Currently the graph dependency is built in the gsn.beans.Modifications class, based on hard-coded wrappers and parameters of those. Adding new communication methods (like zeromq) needs then to modify this.
A workaround was implemented in the virtual sensor loader, by loading files in the lexical order if not contradicting the graph from Modifications.
But to make it explicit, one could add field in the vs xml file and then the dependency graph could be built from that. Of course then the ordering is let to the user, who can then make mistakes...
The virtual sensors loader can also be resilient enough to re-try loading vs that failed until all are launched, independently of the order.
The text was updated successfully, but these errors were encountered: