The current Server implementation inside the feat.ego_server_run branch only supports a single collaboration. I want multiple collaborations to be queued or even running on multiple threads at the same time. As all the sources are to be read only there should be no race conditions on any of the sources while reading.
How to resolve this issue?
Design a strategy to identify unique collaborations and their entities. One option is to append a CollaborationID in front of every AddressRef like {collab_id}/{collaborator}/{address_type}/{address_name}. A collaboration will have the same id if none of the addresses are modified. We can use some hashing strategy to distinguish changes inside the collaboration package and update ids accordingly.
Description
The current Server implementation inside the
feat.ego_server_run
branch only supports a single collaboration. I want multiple collaborations to be queued or even running on multiple threads at the same time. As all the sources are to be read only there should be no race conditions on any of the sources while reading.How to resolve this issue?
Design a strategy to identify unique collaborations and their entities. One option is to append a CollaborationID in front of every
AddressRef
like {collab_id}/{collaborator}/{address_type}/{address_name}. A collaboration will have the same id if none of the addresses are modified. We can use some hashing strategy to distinguish changes inside the collaboration package and update ids accordingly.