Need a good shared object model (Or something like it...)
Written by
on
in
Young Coders.
Spent the afternoon sitting down to write a little application for the OLPC. In particular, wanted to create a multi-player Reversi game. Just a simple little program that would let 2 people connect and play the game.
By way of reference, it took a couple of hours to code this up in VRML and Javascript on top of the Holodesk (Living Worlds) Mutech (Multi-user Technology). That worked quite nicely because there was already a structured (generic) state-sharing protocol available (the Mutech).
To make a static model a shared application I created a SharedObject with certain shared fields (the shared state of the application) and event-handling scripts and routed them to and from the graphics primitives (3D scenegraph) such that clicking caused events to propagate to the scripts/shared objects and then the game state updates were routed to all the viewers via the shared object machinery.
Telepathy, it seems, is more like a SIP protocol (or a Game Lobby protocol) than a transmission protocol. It just arranges to have you connect via some other protocol, it doesn't give you a structured shared object model AFAICS. May want to look into the new Perspective Broker stuff to see if it can give us a reasonably scalable "native" state-sharing mechanism.
I also spent some time on Glade... it doesn't really seem to be targeted at canvas/graphics operations/interactions. I was hoping I'd be able to draw graphics and hook up events on them to get the interaction working. Guess I'll have to code everything by hand in Cairo or PyGame instead... hmm.
I don't see the equivalent of a DOM in Cairo, it seems like it only uses the RSVG library to render SVG? I'd hoped to be able to define events on the SVG groups to create application interfaces. Maybe have to embed the gecko control to get that kind of functionality... at which point we could just code web/ajax applications and be done with it.
Oh, also spent quite a while looking through PyGTK applications looking for those which might be ported. Quite a few candidates available. Not many network-aware ones, though.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Mike C. Fletcher, the VRPlumber, is a philosopher of design turned computer programmer based in Toronto, Canada. He works primarily in the Python programming language, and maintains a large number of Open Source software packages. You can reach him at: mcfletch@vrplumber.com.
Tim on 03/27/2007 4:23 a.m. #
It sure sucks when you expect seemingly simple support for basic things, and find it not there. Then switch to an alternate method, which surely supports it, and it's not there either. And then hook up something else, and find also it's not really there. And then get to that point where you think you'll have to code it yourself... after all it's not that big of a deal really... but damn it, you shouldn't have to... and all that time spent looking... <br />
<br />
Seems to happen to me all the time. (Though in my case I also have the sneaking suspicion that i'm just simply missing something fairly obvious at least half that time...)<br />
<br />
At your PyGTA talk I was a bit intrigued to hear that OLPC dropped supporting jabber protocol. I was curious as to what the reasons for that were. But now i'm off on an irrelevant tangent.<br />
Tim on 03/27/2007 4:53 a.m. #
BTW, consider ye olde Pyro at all? (I periodically keep wanting to try to do something with it because it seems so convenient and simple and small (and, it claims, fast)... looks quite hackable... but then i always end up just adding another XML-RPC call to the zope server to satisfy my basic needs quickly... because apparently i don't want small and fast that badly... sigh.)<br />
<br />
Then again, maybe OLPC should be zope based. (-: ZODB on flash... whee.<br />
Mike Fletcher on 03/27/2007 10:49 a.m. #
I don't think they dropped the Jabber protocol, Gabble, which plugs into Telepathy is AFAIK a Jabber system. They just decided to use a higher-level library that integrates with multiple IM/VoIP systems, rather than relying directly on Jabber.<br />
<br />
I did consider just using PyRO. AFAIK it's just a remote method invocation system. I was hoping for something with more automated semantics (i.e. shared state coordinated automatically by the system). But maybe I should look at it again, given that the other alternatives are also remote method invocation style operations.<br />
<br />
I know that the Twisted stuff is explicitly contemplating multi-user operations, that is, I have an token representing object X on server Y, I can pass that token to server Z and have Z able to access Y, possible through me, possibly directly. It's also got some worrying security-by-obscurity choices (access is simply by guessing a name), but we can deal with those if the protocol is basically usable.<br />
<br />
Still, for new programmers I want something with more automated semantics than raw remote method invocation. Maybe just some "common" objects that do the "right thing" for common shared-state operations using a messaging/RMI system.