[s-xml-rpc-devel] Defining remote functions

[Frédéric Brunel]

> I do like the general idea, maybe we could add the macro to 
> extension.lisp - I would like to have some more time to think over all 
> possible implications.

You're right, I didn't think about the weak points of this method. I 
try to do
more experiment with it.

>> Of course, we should also wrap and unwrap some type convertions not 
>> to see anything about the XML-RPC types.  I guess the function should 
>> also accept HASHTABLEs to be converted in XML-RPC structs.
>>
>> What do you think?
>
> There is a kind of problem with xml-rpc concering type conversions: 
> xml-rpc itself supports only a limited number of types with no 
> possibility to annotate them. I you want automatic conversions (like 
> we have implemented it now), this will only take you one part of the 
> way: for example, now cl sequences (lists and vectors) map to xml-rpc 
> arrays, but when you get back an xml-rpc array you always get a list. 
> Mapping cl structs, clos objects and hashtables to xml-rpc structs 
> would work, but there would only be one return type.

You're right but IMO you should decide a fixed number of types to be 
accepted
by the XML-RPC interface. The Java implementation of XML-RPC accept 
only Hashtables when dealing with XML-RPC structures. I think you can 
do the same. Instead of building a XML-RPC-STRUCT, use a HASHTABLE. The 
only problem is with TIME since
there is no TIME object in ANSI CL (too bad) you'll have to do it 
yourself like
you did.

> The alternative (which is a lot more verbose) would be explicitely 
> specify the xml-rpc call signature so that more complex (and usefull) 
> conversions could be done (much like ffi). You could then say for 
> example that a certain clos object is expected and converted to and 
> from an xml-rpc struct. But this would then need to be extended to 
> composite types, like arrays of a certain element type, or member 
> types for slots ...
>
> All this could be a very interesting and usefull extension. But one of 
> the strengths of xml-rpc is its simplicity, especially in a dynamic 
> language like lisp.

Hmm. I think it's not a good idea. SOAP for example do this kind of 
thing and
is too complex and too verbose. XML is good as far as simplicity is 
concerned. Keep it simple or it won't be used and from my experience, 
using XML Web services to send complex data and structures is just 
insane.

> Thanks for the feedback, frederic,

You're welcome.

-- 
Frederic Brunel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 155 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <https://mailman.common-lisp.net/pipermail/s-xml-rpc-devel/attachments/20040622/d583a5c6/attachment.sig>