From: "J. Ali Harlow" <address@hidden>
To: m m <address@hidden>
CC: NetHack Proxy mailing list <address@hidden>
Subject: Re: slashem proxy interface
Date: Thu, 25 Jan 2007 18:54:36 +0000
On 2007-01-25 03:18:20 PM, m m wrote:
Hi Ali,
Apologies for circumventing the official slashem dev list, my
reasoning is that I'm still very much in the concept stage, and want to
get my ideas better formed before making any noise online. If you think
it would be more appropriate asked there however, let me know and I can
redirect.
I guess the proper place would be nhproxy-discuss, to which I've CCed
this. No exactly a high volume list, but it does mean the discussion will
be preserved for posterity :)
Basically, what I am considering is a web interface for slashem, using
the proxy interface, php and some ajax - the php script starts an
instance of slashem and connects to the proxy interface. It then
processes the messages, and sends updates to the browser via an xml ajax
interface, then returns player input. I'm still researching the viability
of it, but nothing I've read so far has lead me to believe it is not
feasible (technically anyway, whether it will run at a usable pace or not
is another matter, but that can be dealt with if and when it occurs).
To get going, I need to resolve a few queries though, which if you
could help me along that would speed things up for me. From what I have
managed to gather, the proxy interface works via a shared pipe, this is
an area I have pretty much zero knowledge about (beyond some theory).
Would you have any example code that shows simply loading up slashem in
proxy mode and receiving and sending a few signals? With that, I'm pretty
confident I will be able to research/hack/bang my head at it until I get
the rest of the stuff I need.
Many thanks,
Martin McCann
To use nhproxy, the PHP script would need to call nhproxy_connect() which
would then deal with encoding and decoding the requests between the PHP
script and a separate slashem process. I guess that would require writing
some PHP bindings for nhproxy (not to mention filling out much of the
missing nhproxy documentation). This would probably be the best way
forward if you're planning to have an "intelligent" server process.
If, on the other hand, you're planning an "intelligent" client process (in
Java/Javascript), you'd probably end up just getting the PHP script to
re-encode the requests into XML. I've never heard of any facility for
loading libraries and bindings onto client machines so it's probably not
practical to try and run nhproxy there (which would be the efficient thing
to do). I guess an alternative would be to re-implement the client side of
nhproxy in Java/Javascript. No idea how fast it would be.
A final option would be to add XML support to nhproxy. The downside of
this is that the existing protocol is designed to be very efficient. XML,
for all it's strengths, is distinctly verbose. With the amount of data
that flies back and forth in NhProxy, this might be important.
If you can flesh your ideas out a bit more, I can probably think a bit
harder about the pros and cons.
Cheers,
Ali.