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

[brett l. <bre...@gm...>]

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.