[Nhproxy-discuss] Re: slashem proxy interface

[m m]

> 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