| RE: [corona-dev] Container and Collaboration Evenets |
|
Summing, in such approach we have: -
something
like association relations between containers (what about the relation direction?) -
we are
going to send “everything” (each event) to “everyone” (each
container) – communication overhead but if for each event the project
container manager would try to detect unique set of container-destinations –
this could be worse -
serializing
closed containers for memory release – good approach but… -
trying
to load serialized container each time collaboration event will arise – don’t
look good -
other
thing is: what information would be lost without delivering it to closed
projects? Edyta From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Everitt, Glenn The support of Collaboration Events between containers is an
important feature. When we talked this morning we thought we would have
subcontainers send events to their parent containers. The problem with
this approach is subcontainers are not really subcontainers but are related
containers (graph structure rather than tree structure), which can result in
cycle when trying to propagate events from container to container. I
think the solution may be easier than I thought. The ProjectContainerManager has a list of active (open)
containers. It also can locate and open containers that are not
opened. In other words, the ProjectContainerManager knows what included
in the unique set of containers. So, if we have a subcontainer (related-container)
request the ProjectContainerManager send an event to the containers we can
guarantee that the container will only get the message once. The simplest
thing to do would be to have the ProjectContainerManager to send the event once
to each container. We could try to get more clever by only sending the
event containers that are related-containers of the container that originated
the event. The ProjectManagerContainer would have to look at each
container and its related-containers and create unique list containers to send
the event. It would mean the ProjectContainerManager would have to do
cycle detection to create this unique set. Personally, I don’t
think it is worth the trouble, I think you can send the Collaboration
Event to all of the Containers and let them decide whether it is an event they
are interested in processing. The container could decide that it is
interested only in CollaborationEvents from related-containers and check its
list of related-containers or it could just ignore the Collaboration Event. One remaining question is if a container is closed and it is
going to be sent a Collaboration Event should it be opened so it can process
the event? The originally thinking on the Container is that we would keep
a reference count and if no clients had a container open it would be saved to
disk and closed to conserve memory. Any thoughts? The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it. |