[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nhproxy-discuss] Re: slashem proxy interface

From: J. Ali Harlow
Subject: [Nhproxy-discuss] 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]