Re: [Rails-devel] Starting on a client/server

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

> Right now, the biggest downside I can foresee is that _all_ 
> clients must
> talk to the server over a transport, which means that even 
> local games will
> have to load up the network bits and talk across the 
> localhost. 

Not necessarily, in my opinion. I had in mind generic API's (interfaces) at
the client and the server side, that would take any sequence of objects at
one side and deliver them at the other side. How that is done is internal to
the transport module, that could have several implementations. For local
play, it is just pass-through; I don't think we need separate programs
communicating through a socket. For a client/server connection through
sockets, the objects would be serialized at one side, sent over the socket,
and deserialized at the other side (each object must know how to
(de)serialize itself). For PBEM, we have SMTP and POP3 as transport
mechanisms (in this case the objects must be accompanied by text). Etc.

My approach would have been first to refactor the current code to this
architecture, and then add the transport through sockets as would just be a
new implementation of an interface. 

> It's a minor
> amount of overhead, though. So other than the conceptual 
> inefficiency, I
> don't think it's a major problem.  The main requirement is 
> that the Server
> will need two methods of startup: a command-line no-GUI 
> method, and through
> the Options GUI for hosting a local Client and Server.

And a no-server Client.
 
> For now, I've decided to just use the native Java sockets in 
> java.net.* and
> java.nio.*. I'll push PBEM support off until the basic 
> architecture is more
> fleshed out. My gut feeling is that real-time network play 
> should be the
> higher priority because there are already workable PBEM solutions.
> 
> I think that maintaining good component separation is going 
> to require that
> we adopt Java's concept of events and listeners. We do that 
> to some extent
> with the Observer objects, but I think it's definitely 
> something that we can
> work on improving.

I have looked hard at events and listeners before I started with
Observer/Obervable, but at that time I concluded that Events wouldn't do the
job for updating the UI. An Observer can register at a unique model object,
whereas a Listener must register at a unique Event. This way, we would need
separate (unique) events for each individual UI field, hex, stock space,
etc. 

Say a stock price token moves from stock chart space D5 to E5. Now the
Observable StockSpace ModelObject D5 sends 'token removed' to UI ViewObject
D5, and E5 sends a 'token added' to its counterpart. This does not translate
directly to events.

If we are going to use events, I think the way to go is to replace this
architecture by one in which the stock chart model as a whole, rather than
the individual spaces, sends events to its UI counterpart, with the involved
squares and tokens as parameters. Similarly the Map model sends events to
the Map UI, and the OR model to the OR window (where we then still need to
somehow identify the individual fields).