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

[Stefan F. <ste...@we...>]

Brett & Erik,
I like the discussion, however sometimes for me it is on a too general level.

I think to decide on how to proceed with the coding it depends on what 
information will have to be exchanged between clients and server and what the 
server will actually do. And I have to admit that I currently have only vague 
ideas what the your actual proposals are. But to change my coding behavior you 
should provide a more concrete plan. I will try to give my idea shortly below.

From my point of view the most realistic way is similar to what VASSAL does, 
which how I understand it, is mainly exchanging messages and each client has a 
complete model of the game.
There are two candidates what to put into those messages: Either the actions 
(like in the save files) or moves (like for the undo/redo stack). Both allow 
to replay the whole game, moves also allow to move backward. Thus on each 
client a complete Rails game runs (with additional code that restricts only 
entering move for one player) and sends messages to all other clients. If this 
is actually done peer by peer, or one client serving as a message relay or a 
centralized sever in-between does not matter much.

All other separations imo require much more efforts in both restructuring old 
code and writing new code.

But most likely the chosen method will depend on the views of the person who 
volunteers to undertake that task.

Stefan


On Saturday, July 23, 2011 10:07:02 pm brett lentz wrote:
> On Sat, Jul 23, 2011 at 12:54 PM, Erik Vos <eri...@xs...> wrote:
> > See below.
> > 
> >  > -----Original Message-----
> > 
> >> From: brett lentz [mailto:bre...@gm...]
> > 
> >  > Because the clients should take the "authoritative" values for things
> > given to
> > 
> >> it by the server, not whatever arbitrary values somebody decides to put
> > 
> > into
> > 
> >> their own local XML files. Trusting the client to do the right thing on
> > 
> > its own
> > 
> >> makes exploitation far too easy.
> > 
> > That's a good point, but if we go that way, it should occur only once, at
> > the start of the game.
> 
> Yup. I think we agree on the basic idea.
> 
> >> > Always local, in my concept.  Static info does not need to squeezed
> > 
> > through
> > 
> >> the client/server interface.
> >> 
> >> > Unless you want to make the client really dumb, of course.  And
> >> > slower.
> >> 
> >> Over-use of static info also makes supporting multiple threads more
> >> problematic; it increases the likelihood of race conditions and other
> > 
> > difficult-
> > 
> >> to-debug issues. In general, most of the stuff that's currently static
> > 
> > doesn't
> > 
> >> really _need_ to be static.
> > 
> > Apologies, I should *again* have said: "static (as opposed to dynamic)",
> > i.e. never changing.
> > I'm as much against "static (as opposed to instance)" as you are.
> 
> Sounds like we're in violent agreement. ;-)
> 
> IMO, unchanging info should be marked "final". So, it'll be "static
> final" and guaranteed never to change after startup.
> 
> The thing I want to begin reducing is the number of non-final static
> declarations.
> 
> >> The response can be a variety of things, depending on how "thick" or
> > 
> > "thin"
> > 
> >> the client is.
> >> 
> >> 1. It could be a simple "success/failure" response.
> >> 2. It could be success/failure, with an updated client Wallet value.
> >> 3. It could be success/failure, with the current state of every player's
> >> holdings, the whole stock market, or even whole game.
> > 
> > OK.  To be more precise, I think we must distinguish three types of
> > server->client info:
> > 1. The response: what only the previously acting player client gets
> > (success/failure, error message).
> > 2. The broadcast: what *all* clients get (i.e. the initial data, the GUI
> > updates and other state-like info).
> > 3. The prompt (or whatever): what only the next active player gets (i.e.
> > the list of allowed actions).  Or will we allow all players to enter any
> > move, as someone suggested?
> 
> No. You'll note that I included authentication as a part of
> client-server communication in my previous description. We need to be
> able to identify that each player only makes _their_ moves (except for
> administrative overrides).
> 
> However, that shouldn't preclude someone from logging in when it's not
> their own turn and just reviewing the current (read-only) state of the
> game; this is, after all, the exact same use case as playing a "live"
> network game where someone is disconnected for whatever reason and
> reconnects, then waits for their turn.
> 
> > Erik.
> 
> ---Brett.
> 
> ---------------------------------------------------------------------------
> --- Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel