| RE: [corona-dev] Container and Collaboration Evenets |
|
I like your summary: -
The
relation direction is from the Container to the Container in related-container
list. -
One
container sends event to the Project Container Manager it sends it to all
of the other containers, can we make it “smart” to reduce the
number of other containers to which events are sent? -
I agree
with comments on processing events when a container is serialized. Do we
just leave them all in memory all the time? Could we only open a
closed container when an “important” event arrives? We
could register an event filter for a container with the Project Container
Manager. If the event doesn’t meet the filter criteria and the
container is serialized the container isn’t opened otherwise the event
does meet filter criteria and the container is open and the event is processes
by the container. Remember if the container is closed it is because no
clients are currently connected to it. From: 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: 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. 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. |