Re: [Rails-devel] Removal of static class variables (git: 8b9df8)

[Erik V. <eri...@xs...>]

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]

> I have to admit that do not fully understand what Brett's concerns are: In
my
> understanding it will either be a fat client/lean server (means that each
> instance has a full game model behind and the server component only
> broker
> messages) or a lean client/fat sever (means that the client only shows a
view
> of game model on the server) and in that case the client would have none
of
> the current Manager which are configured by xml.

The current exchange of action objects is based on (what I think amounts to)
yet another concept, that I mentioned a few days ago in the Game Notes
thread:

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> For what it's worth:
> 
> My idea about client/server was that both sides would parse the XML and
> thus would have access to all static (as opposed to dynamic) objects.
> Only the dynamic (state) info would be in the server only.  Parsing at the
> client would been initiated by much simpler (and probably less) managers,
> probably not really worth that name.
> 
> But I haven't really thought this through yet.

The current communication between GUI and engine mainly consists of the
action objects.  After a client/server split, the action objects would be
exchanged in some serialized form,  and only contain the unique IDs of the
relevant objects, not these objects themselves (which are declared
transient). 
So the unique IDs have to be identical at both sides. I consider that a main
design consideration for the client/server split.  It may put constraints on
the parsing sequence at both sides.

Erik.