Re: [Mldonkey-users] Server interfacing

[Chris Chabot]

Thanks for the pointer, i'll take a look at it, while i do think it
might be a nifty trick to pull from a scripting language. Gues i might
be on my way to code a php module in C.

I do agree that SOAP is also a very good option;  Especialy if you take
all the variable type factoring into considerations.. this way more
powerfull clients could be build, etc. Might even replace its
propriatairy gui protocol?

Anyways, i hope one of these days this will be interesting to the
mldonkey developers. I love the product, but would strongly prefer a
slim & fast core, with a interface external clients (be it web,
gui, or whatever) could use to provide UI services. 

    -- Chris

luculus wrote:
> Hi!
>
> Am Montag, 27. Januar 2003 03:41 schrieb Chris Chabot:
> > .ini files, and telnet connection to collect all the
> > information.
> >   
>
> Which is tedious and error-prone. Have a look at the GUI-Protocol, which is 
> briefly described in interface_protocol.txt in the source distribution. It 
> has the advantage, that you just have to build the handling code for the 
> packets you are interested in. The details for dataypes and un-/marshaling 
> are available in the sources (guiTypes.ml, commonTypes.ml, guiProto.ml, 
> guiDecoding.ml, et.al.).
>
> I would say that XML is nice but why not go a step further and use SOAP? This 
> would also take care of the tedious un-/marshaling. I think there is no need 
> for the core and the gui to use a similar protocol like the core uses to talk 
> to servers and peers, besides the code reuse. In the latter case efficiency, 
> size and performance are crucial with 1:n connections (>10³). In the former 
> case you can go for convenience, because with 1:m connectins (<10) the 
> overhead of XML and the marshaling isn't too much of a burden for the core.
>
> The effort of using SOAP to implement the GUI-Protocol depends on whether the 
> mldonkey developer team wants to support easy implementation of a wide 
> variety of GUIs written in other languages than ocaml. This could be true, if 
> the team decides to concentrate on the core development.