[Nhproxy-discuss] Re: slashem proxy interface

[J. Ali Harlow]

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.