| john robinson 2006-07-21, 1:11 am |
| It's been a while since I've participated in the list... forgive me if
I'm off base.
What does this global_so store about the rooms? My guess is that it
stores an object with some simple properties... ie.. name of the room
and number of users.
If that's the case, what I would do is have the one global_so that
every chat room proxies (read-only) from the global server. Then,
whenever someone joins or leaves a room, or when a new room is
instantiated, you'd use nc.call to tell the global server what has
changed. The global server would then handle updating it's global_so
and the chat servers/rooms would receive their onSync event. Hopefully
that makes some sense. If not just holler, either I or someone else
here could probably whip up some quick example code for you or explain
a bit better.
john
On Jul 20, 2006, at 10:42 AM, David wrote:
> Hi All,
>
>
>
> We are trying to create a chat application with different chat rooms,
> on
> different FMS servers where all chat rooms should be updated on the
> status
> of the other chat rooms.
>
>
>
> In order to achieve this we have set up a local_so_manager- and a
> global_so_manager instance on each server
>
>
>
> When instantiated the local_so_manager makes a connection to the
> global_so_manager.
>
> The local_so_manager maintains a temporary shared object which holds
> the
> information of the different chat rooms available on the same server
> and a
> proxied shared object of the global_so maintained by the
> global_so_manager
> (see below)
>
>
>
> When the global_so_manager is instantiated it connects to the
> local_so_managers and sets up proxied shared objects for each of the
> local_so_managers.
>
> When the proxied shared objects are updated the global_so_manager sets
> their
> properties in its global_so
>
>
>
> When a chat room is instantiated it connects to the local_so_manager.
>
> It uses this connection to get the local_so_manager's proxied shared
> object
> of the global_so (i.e. it has a proxied shared object of the
> local_so_manager's proxied shared object of the global_so_manager's
> global_so)
>
>
>
> The problem is although all shared objects are updated correctly after
> instantiating the applications, after a few minutes we get an onSync
> event
> on the local_so_manager which is not (deliberately) triggered by us,
> with
> the code: "clear" and effectively clearing its proxied global_so. At
> that
> point the global_so on the global_so_manager is still up to date but
> everything else is out of sync.
>
>
>
> Is this solution the right way to go for our project or do we need to
> do
> this in some other way. And if it is the right way to go, how can we
> fix it
> so it will work? For example what would trigger those 'clear' onSync
> events,
> and how do we stop them from firing?
>
>
>
>
>
> Thanks,
>
> David van Kooten
>
> david-mXg03kgCt+es6CcaKjlrPw@public.gmane.org
>
>
>
> ________________________________________
_______
> FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
>
________________________________________
_______
FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
|