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.