Enough SUIDs to support mulitple users accessing single instance via CyREST?

[AlexanderPico]

Originally suggests by jorge on api repo.... moved here for relevance: https://github.com/cytoscape/cytoscape-api/issues/8

Basically, do we have SUIDs in enough places to support independent users accessing a single hosted instance of Cytoscape and not clobbering each other's work? At the network level, I think we might. But we would need SUIDs for styles and few other things as well.

Worthwhile mocking up a trial and seeing what breaks...

[AlexanderPico]

The test would go something like this...

1. Get Cytoscape running on a server with x-windows handling the mandatory GUI.
2. Connect to instance via CyREST from 2 or more machines.
3. Attempt various workflows and see what breaks.

The thought experiment alone reveals some initial results...

• Network SUIDs already serve as a handy randomly generated ID to keep users' network refs unique. However, in this mode, we might also need to include the SUID in a concatenated network name (at least behind the scenes) so that two users could name or load the same pathway (e.g., galFiltered).
• Styles would be clobbered currently. There rely only on names. Do we need an SUID for styles and a set of default styles (with concatenated SUID names) for each user? Or make the defaults immutable and use SUID concatenated names just for user generated styles?
• Tables rely on network SUIDs, so they should work. Except, what about unassigned tables?
• Save/Export would need to be limited to the networks/views handled by a particular user.
• We would want to limit/block a set of other commands as well, e.g., those that control general session prefs or UI. Note that even a very limited hosted Cytoscape solution would prove extremely useful at making a set of functions immediately available as services, i.e., a prototype of CI?

Alternately, we should weight the complexity of supporting this against the multi-instance strategy where we launch a unique Cytoscape session per user. How do these two scale when dealing with dozens, hundreds or thousands of users?

This would be a "quick'n'dirty" prototype of what we could do with a headless version of Cytoscape as well. And eventually package and doc these solutions so others could host their own Cytoscape services.

[dotasek]

I could try this in the lab; I've already been able to communicate with my Cytoscape from other computers.

A few things I think would break:

• Swing Events are still a point of failure, even with one user.
• Some Tasks require synchronous execution. No idea what would happen to those.
• A lot of Tasks and actions require a current network. That would turn into a crapshoot with multiple users, and there's no telling which apps use those.

And of course, Styles and Mappings would be shared between users, and would require some renaming and hiding, etc.

[bdemchak]

... and to pile on ...

Users would be free to view/manipulate each others' networks.

... also to reload/clear the entire session.

... we would need to be very sure the CyREST commands are serialized ... Cytoscape's threading model would be pushed hard if not.

Probably a bad idea unless use cases were well constrained. We'd have to know more about the intended use case. We could not endorse this for unrestricted use.

[AlexanderPico]

1) We could make it so users would NOT be free to view/manipulate each others' networks. That's the point of using SUIDs as a sort of filter for what's visible/accessible by each user. They should be totally unaware that other networks are in the session.

2) That would be blocked.

3) Yes, 100% agreed. If this will work at all, it might work for well-constrained use cases. Like you, I was also thinking layouts. Might be a quick and cheap way to get service-based layouts!