[prev in list] [next in list] [prev in thread] [next in thread] 

List:       atlantik-devel
Subject:    Re: [atlantik-devel]  [cap@capsi.com: [monopd-devel] auctions, debts,
From:       Erik Sigra <sigra () home ! se>
Date:       2003-07-09 5:53:13
[Download RAW message or body]

onsdagen den 9 juli 2003 07.39 skrev Rob Kaper:
> On Wed, Jul 09, 2003 at 07:06:29AM +0200, Erik Sigra wrote:
> > That does not sound like a bug at all. But there are certainly many
> > things that need to be addressed before a 1.0 release.
>
> Care to sort out the priorities with me?
>
> I want to stay away from the new object XML and reworking the board
> rendering for monopd 1.1, but I'm not sure on the other issues.
>
> As far as gameplay goes, the single feature missing to have a 100% complete
> implementation of Monopoly would be the possibility to trade cards and to
> allow debt consilidation as part of trades.
>
> There's one outstanding Atlantik crash in the trade dialog, but that is
> very likely to be fixed in 0.5.3, but I'm reluctant to close it. The only
> other serious problem are the misplaced game buttons, but I haven't been
> able to reproduce that anymore either. Other than that, Atlantik is nearing
> 1.0 though.. translating monopd messages (or rather, trying to remove them
> where possible) could be a priority from KDE's perspective, though.

Yes, this is very important. The server should never send text that the client 
just shows. It must send the message in a form that the client code can 
understand (a code or XML tag) and then the client formulates a message text 
that is translated into the language of the user. In the case of buttons, the 
server should not send buttons directly, but send whatever the client needs 
to know to enable/disable appropriate KActions.

The patch http://bugs.kde.org/show_bug.cgi?id=54538 was inteded to solve an 
instance of this bug.


Another thing, I assume this could happen:
1. A user decides to acept a trade.
2. The server updates the trade.
3. The user clicks "Accept". But now he accepts the updated trade,
   which is not what he intended to accept.

The obvous fix would be to disable the accept button for a few seconds
after a trade has been updated so that the user has a chance to notice
the update. But that is not enough, because this could happen:
1. A user decides to accept a trade.
2. The server updates the trade.
3. Before the update reaches the client across the network, the user
   clicks "Accept" and the client sends an accept message.
4. The server receives the accept message and assumes that the client
   accepted the updated trade.

The obvious fix for this would be to have revision numbers for the
trade. Together with disabling the accept button for a few seconds
after updates, this would solve the problem completely, because:
1. The server sends a revision number with each update of the trade.
2. When the client accepts a trade, it does not just send ".Ta" and
the ID, but also the revision number that it accepts.
3. The server only handles trade accept requests where the revision
number is the newest (highest) revision number for that trade ID.

_______________________________________________
atlantik-devel mailing list
atlantik-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/atlantik-devel
[prev in list] [next in list] [prev in thread] [next in thread]