headers
Jason McIntosh | 4 Aug 23:22
Picon

Various updates

* I've updated bookkeeper <at> volity.net/volity to understand and store
the new, seat-friendly game record format, as described on the Wiki.
Code changes checked into CVS.

* I've done a few bugfixes to the Perl server code (mostly involving
game record generation), checked them into CVS, and restarted
rps <at> volity.net/volity to use it.

* I've taken eights <at> volity.net/volity off-line for the time being,
since it's just fallen behind, protocol-wise. Between my RPS and all
of Zarf's test parlors, I think we have enough testing platforms to
carry the client and website work that needs to be done this month.

I think I'm going to declare what I have to be the 0.5 release of
Frivolity. Look for that later this week.

--

-- 
  Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Permalink | Reply | 0 comments |
headers
Jason McIntosh | 5 Aug 07:40
Picon

Frivolity 0.5.0 released, plus Python stuff

Hello, it's jmac, making my apparently annual post to the volity-announce list.

Since May, we've been working hard making Volity less of a moving
target, spending more time hashing out the finer points of the
protocol than hacking on code. As always, refer to the Wiki to see the
current state of things, and the volity-devel mailing list archives to
see how we got here.
* Volity Wiki - http://volity.org/wiki
* Volity-devel archives -
http://sourceforge.net/mailarchive/forum.php?forum_id=35724

Zarf has joined the development effort in a major way, implementing
most of Volity in Python. It's not as complete as the Perl stuff
(yet), but it's enough to create playable parlors in Python.
* Zarf's Volity page - http://eblong.com/zarf/volity/index.html

Meanwhile, I have released version 0.5.0 of Frivolity, the Perl
implementation of the whole protocol (parlor, referee, bookkeeper, and
a cheesy text-only client). I expect this to be the last major release
of these libraries before we go to beta; coding efforts have now
shifted to getting Javolin ready for public consumption.
* Frivolity - http://www.volity.org/projects/frivolity/

We still hope to have a public beta of the whole system up within a
few weeks. Stay tuned.

--

-- 
  Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Orleans | 14 Aug 21:29
X-Face

[META] minor protocol request

After doing some archeology on the Volity Sourceforge site, I have two
requests:

Don't use the same CVS commit message for multiple files unless the
delta really requires all the files to be checked out as a unit.  For
example, I was looking at the commit log for
Javolin/source/org/volity/jabber/RPCHandler.java to see what changed,
and it lists a whole bunch of other changes that are completely
unrelated (and doesn't even actually mention what changed in
RPCHandler-- just a doc comment, it turns out).

When you start a new thread on one of the mailing lists, don't do it
by replying to an old thread.  I went looking for the RPC discussion
from last month in the volity-javolin-dev archives, but it doesn't
show up on the top-level page; it's actually under the "Javolin now
uses Batik 1.6" thread.

Neither of these is that big a deal-- and I've probably broken both
rules myself-- it's just that now that we have four (or more) active
developers touching the same code, I think we should be a little
better about clarity and traceability.

Thanks,
--Doug

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andrew Plotkin | 18 Aug 17:10

Number handling in RPCs

Jabber-RPC differentiates int and float. So does Python. Perl doesn't. 
ECMAScript doesn't.

This led to gears clashing in my test game code. I had the ECMA UI doing 
this:

   rpc("move", x, y);

...where the x and y values were Number objects with integer values. 
Generated by Math.floor(), in fact, although the same thing would have 
happened if I'd used literal values, e.g.:

   rpc("move", 4, 3).

Since ECMAScript doesn't care about the int/float distinction, these come 
out of Rhino as Java Double or Float objects. RPC.py translates them to 
Jabber-RPC <double> tags. (<double>4.0</<double>, <double>3.0</<double>.) 
They go over my referee, which translates them to Python float objects.

Then my Python game code chokes, because it's expecting ints. It's got 
lines like:

   def rpc_move(self, xpos, ypos):
     val = board[xpos][ypos]

...and Python doesn't allow you to access a linear array with floats, even 
if the floats have whole-number values. You get a type-mismatch exception, 
which bounces back to the client as an RPC fault (608, internal error).

(Actually, I am simplifying the situation. It really chokes because I
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jason McIntosh | 19 Aug 20:49
Picon

Re: Number handling in RPCs

On 8/18/05, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
> 
> * Second case: We tweak the Javolin code to convert Javascript numbers to
> ints where possible. This is the same procedure as above, only in the
> client rather than the (Python) referee.
> 
> Games which use floats will still have to accept ints, as in case 1.

I am fine with this solution for now.

--

-- 
  Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Permalink | Reply | 1 comment |
headers
Doug Orleans | 19 Aug 22:44
X-Face

Re: Number handling in RPCs

Jason McIntosh writes:
 > On 8/18/05, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
 > > 
 > > * Second case: We tweak the Javolin code to convert Javascript numbers to
 > > ints where possible. This is the same procedure as above, only in the
 > > client rather than the (Python) referee.
 > > 
 > > Games which use floats will still have to accept ints, as in case 1.
 > 
 > I am fine with this solution for now.

I agree.  I'm not entirely sure where to do it, though.  I was
thinking it could be done in
org.volity.jabber.packet.RPC.getValueXML(), but it should probably
happen further upstream, i.e., if someone gives 42.0 to the RPC code,
it should be sent as a <double>, not an <int>.  So I guess it should
happen before calling org.volity.client.Referee.invoke(), namely in
the "rpc" callback in GameUI, which is where we first get our hands on
the ECMAScript parameter values.  I'll try that out this weekend,
unless someone else gets to it first.

--dougo <at> place.org

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Permalink | Reply | 0 comments |
headers
Doug Orleans | 19 Aug 23:45
X-Face

Re: Number handling in RPCs

Andrew Plotkin writes:
 > * First case: we accept that RPCs coming from the client will never 
 > contain <int> values. I tweak my Python referee code to convert floats to 
 > ints where possible (before type-checking occurs).

On second thought, I think I prefer this solution.  If we're going to
enforce (or strongly encourage) UIs to be written in ECMAScript, we
should use its type system as the type system of rulesets, and let
everything else deal with that.  And frankly I favor type systems
where numbers are just numbers and you don't have to care about the
internal representation.

Or actually, I think I would prefer a more general solution: any
parameter or return value that is defined by the ruleset to be a
"number" may either be an <int> or <double> in the Jabber-RPC payload,
and clients and referees must be able to handle both as input (but can
choose to output either one).  This gives implementations a little
more leeway, so they could send <int>s if they really wanted to.  Or
maybe it would be simpler to just discard the <int> type altogether.  I
don't have a strong opinion about this at the moment.

The only thing I worry about is whether round-off errors in
floating-point arithmetic can produce numbers that should be integers
but are not, and which might get rounded off in the wrong direction.
For example, in PLT Scheme:

> (- 1/3 (/ 1.0 3.0))
1.8512752095189988e-17
> (integer? (- 1/3 (/ 1.0 3.0)))
#f
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Plotkin | 23 Aug 16:09

More on table-join timing

(Thread carried over from Javolin-devel.)

Two weeks ago, Jason said:

> Javolin is currently having the user join the table's MUC too early.
> It sends the user to the MUC as an asynchronous activity while
> initializing the table window. However, since the GameUI object that
> builds the RPC-dispatcher objects gets created as a step of UI
> creation, the new RPCs that the referee sends the instant it sees a
> new player -- such as seat_list and receive_state -- fall on deaf
> ears.
>
> I mentioned this to Doug on IM, and we bounced around the idea of
> delaying the actual MUC joining until the UI was actually rendered.
> Does this sound good to y'all?

It did then, but as I try to upgrade Javolin, I'm finding that it's not 
sufficient. There are cases where the client really needs to join the MUC 
*before* it creates the UI.

(The case I found is where the client is trying to join a table, and all 
it has is the table JID -- not the referee or parlor JIDs. In this case, 
the client must join, look at presence, and do some disco queries in order 
to find out the ref JID and the UI URL.)

Doug proposed that the referee *shouldn't* send all the state RPCs to 
every Jabber entity that joins, as soon as it joins. Instead, it should 
wait for a query. This sounds like a better idea. I think it will save 
headaches.
(Continue reading)

Permalink | Reply | 503 comments |
headers
Andrew Plotkin | 23 Aug 18:53

Re: More on table-join timing

(yes, I *do* always wind up replying to myself. Think of it as the 
value-pak edition.)

On Tue, 23 Aug 2005, Andrew Plotkin wrote:

> Doug proposed that the referee *shouldn't* send all the state RPCs to every 
> Jabber entity that joins, as soon as it joins. Instead, it should wait for a 
> query. This sounds like a better idea. I think it will save headaches.
>
> Conveniently, we already have such a query defined: the volity.send_state 
> RPC. The client should send this as soon as it's ready to receive RPCs. The 
> referee will take the appropriate action (send a spate of config and seating 
> info, wrapped in receive_state/state_sent) but it will also set an internal 
> flag indicating that this client is a functional Volity client.

Looking at the code, I see that volity.send_state is defined to send 
config and game state, but *not* seating info. (By "seating info" I mean 
volity.seat_list, followed (optionally) by volity.required_seat_list, 
followed by enough volity.player_sat calls to define the current seating 
state.)

I can't think why you'd want to request a state dump and *not* get the 
seating info. So, add to my proposal: volity.send_state should include 
seating info as well as configuration and game-state data. In fact 
volity.send_state should do exactly what referees currently do at 
player-join time.

If there's some reason to have two levels of state dump, and I've 
overlooked it, please post. It would be trivial to do. (Either have two 
calls -- volity.send_state and volity.send_initial_state -- or stick a
(Continue reading)

Permalink | Reply | 503 comments |
headers
Jason McIntosh | 23 Aug 20:47
Picon

Re: [Volity-javolin-dev] By the way

On 8/22/05, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
> 
> Now, to create a GameServer, you need the server's JID. Where do you get
> this? We don't have it, nor do we have the referee's JID. As far as I can
> tell, the only way to get either JID is to join the MUC and do a disco on
> the referee. (The MUC won't permit any querying of MUC members, including
> the referee, until you join. You can't even get the list of members.)

There is a way around this, but it relies more on how I have things
written in Frivolity than how I have things defined in the spec (such
as it is).

You _can_ query the referee, if you can learn its true JID. And in
Frivolity, that JID is always knowable through this formula:

[the parlor's base JID]/[the node-part of the MUC's JID]

So, the referee of funtable42 <at> conference.volity.net, a table within
the parlor game <at> foo.com, is game <at> foo.com/funtable24.

We could put this behavior into the spec, but it makes implementation
a little haier... AFAICT you'd have to create the table with the
parlor first (to guarantee the name's availability), then spawn the
ref with that resource string, then (as table creator) grant the ref
owner-level powers over the table so it can enter and do its thing.

I have to say though it's an unpleasant surprise that you can't disco
a non-anonymous table... I really thought it was otherwise. Is this
behavior defined in he Jabber spec?
(Continue reading)

Permalink | Reply | 1 comment |

Gmane