[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Nhproxy-discuss] Re: slashem proxy interface
From: |
m m |
Subject: |
[Nhproxy-discuss] Re: slashem proxy interface |
Date: |
Fri, 26 Jan 2007 00:53:08 +0000 |
If you go for the simple case of a PHP app that uses the nhproxy library
to do the communication with slashem and the re-encodes the requests into
XML for the javascript client, then "all" you need is to design XML
equivalents for the NhExt protocol and implement them.
I've been doing a bit of further research and thinking, and am more inclined
to think that a further layer is, if not required, at least going to make
things a lot easier.
The main problem with php being the main engine is that it is none stateful
- it would need to come up with clever ways to keep the slashem process
running while it stops and start at each server request. So having a further
layer will handle this limitation. I am thinking a 'game deamon'. Something
like this
1. user launches browser, starts a new game
2. javascript sends a xml packet to the php module to ask for a new game
3. php module connects to 'game deamon' requesting new game
4. game deamon starts a slashem instance, assigns an id, does all the
initialisation, then sends the screen to php (keeping a copy in memory)
5. php sends the screen as xml to javascript module, along with session
id
6. javascript module displays screen, waits for input
7. input made, javascript sends xml packet to php module (along with
session id)
8. php module communicates packet contents to game deamon (either sends
the xml directly on, or translates to another protocol if prudent) along
with sesison id
9. game deamon translates the packet to the relevent messages to the game
assiciated with session id, recieves return packets and builds the new
screen. It then sends the differences between the new screen and old to the
php module.
10. php module sends the screen updates to the javascript module
11. javascript module updates the screen changes, and awaits for input
12. goto 6
So the php module becomes little more than a middle man, at most
translating between an xml packet for javascript, and a more efficient
method for the game deamon. Indeed, it seems to suggest that it is not
needed at all, and the game deamon could handle the http elements itself and
do away with the need for php (and apache etc.) all together, but at later
stages the ability to add extra management features in easily with php makes
it a more desirable feature (user management, old scores etc.)
The javascript module is, and should always be, simply 'display x tile at
y, x' and 'send z key'.
Apologies if this all sounds a little fuzzy, I've got a pretty good idea
in my head on how it will work, but perhaps not articulating it too well at
this point. It doesn't change the immediate tasks though, which is still to
get a proof working. I've got the big 'advanced programming in the unix
environment' book of the shelf and am looking into RPCs, but I fear without
a more directed approach I could take quite a few wrong turns, so a trivial
example would be great.
In the meatime I will get the latest cvsup and do some more reading up on
it.
Cheers,
Martin
There are quite a few issues that will need addressed, but primarily
I'm aiming to get a proof of concept done, to make sure it is technically
possible (I see no reason why not atm). Once that is done, the
practicalities can be addressed. This is mainly as a learning project for
me, so I'm not too worried if it turns out to be unfeasible and needs to
be dropped :)
My first set of steps is to get familar with the proxy code, so my
tasks are
[1] compile slashem with the proxy interface - done
[2] run the proxy interface tests - done
[3] Write a quick C app to show it working (launch slashem and
demonstrate it has recieved and sent a message)
[3] is the bit I am stuck at at the minute, though I think by
hammering away at the test code for the proxy module I may be able to
piece it together. However, any suggestions are very welcome :)
First, make sure you're using the development branch of slashem and either
cvs nhproxy or at the very least version 0.9.
I'll see if I can find some time to write a complete trivial example. The
existing one in the nhproxy manual is a little _too_ trivial!
Alternatively, you could look at gtkhack as a rather non-trivial example.
Cheers,
Ali.
_________________________________________________________________
Buy what you want when you want it on Sympatico / MSN Shopping
http://shopping.sympatico.msn.ca/content/shp/?ctId=2,ptnrid=176,ptnrdata=081805