From rudi at constantly.at Sun Jun 13 14:20:37 2004 From: rudi at constantly.at (Rudi Schlatte) Date: Sun, 13 Jun 2004 16:20:37 +0200 Subject: [s-xml-rpc-devel] Added some introspection Message-ID: Hi, I've added system.listMethods, system.methodHelp (and a dummy system.methodSignature) to s-xml-rpc. I've also created a "secure by default" package that contains only these three methods and bound *xml-rpc-package* to this -- we don't want to export the whole common-lisp package by default, I think. I've also added a ChangeLog file to record my misdeeds. Next up: system.multicall! Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From rudi at constantly.at Sun Jun 13 16:22:04 2004 From: rudi at constantly.at (Rudi Schlatte) Date: Sun, 13 Jun 2004 18:22:04 +0200 Subject: [s-xml-rpc-devel] system.multicall implemented Message-ID: Hi, So system.multicall is implemented in CVS as well. See http://www.xmlrpc.com/discuss/msgReader$1208 for the spec. I multi-called some methods from Python and it looked ok (both normal return values and faults "looked the same" as the examples in the spec). I introduced a literal string so the fault structures can be stuffed in the result array without being turned into strings with xml in them. Now all of the xml-rpc extensions I know of are implemented; if there's another one I'll likely move the lot into their own file so they don't clutter up the main server code. Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From frederic.brunel at free.fr Thu Jun 17 18:20:51 2004 From: frederic.brunel at free.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Brunel?=) Date: Thu, 17 Jun 2004 20:20:51 +0200 Subject: [s-xml-rpc-devel] Defining remote functions Message-ID: <10396097-C08B-11D8-8C76-000A959C96CC@free.fr> Hi, By googling the Web for an XML-RPC implementation in Common Lisp, I found S-XML-RPC and other one for Corman Lisp. I'm glad that S-XML-RPC is now part of Common-Lisp.net. By the way, looking at the Corman Lisp API for XML-RPC, I found interesting that it have the ability to define a standard function embedding an XML-RPC call. How about implementing this kind of thing in S-XML-RPC? I wrote the following lines of code: (defmacro define-xmlrpc-method (name args &key url method) `(defun ,name ,args (xml-rpc-call (encode-xml-rpc-call ,method , at args) :url ,(puri:uri-path url) :host ,(puri:uri-host url) :port ,(cond ((puri:uri-port url)) (t 80))))) (define-xmlrpc-method get-state-name (state) :url #u"http://betty.userland.com/RPC2" :method "examples.getStateName") (define-xmlrpc-method get-time () :url #u"http://time.xmlrpc.com/RPC2" :method "currentTime.getCurrentTime") ? (get-state-name 41) "South Dakota" ? (get-time) # I rely on the great PURI package to parse URL. Quite straightforward. 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? -- 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: From rudi at constantly.at Thu Jun 17 19:51:02 2004 From: rudi at constantly.at (Rudi Schlatte) Date: Thu, 17 Jun 2004 21:51:02 +0200 Subject: [s-xml-rpc-devel] New extensions Message-ID: Hi, I just checked in support for system.getCapabilities and added standard error codes (I hope I didn't miss any places). The stuff beyond the basic protocol now lives in extensions.lisp, and there are some tests (not comprehensive at all, but it's a start). Lastly, it's now possible to send symbols over the wire; they are encoded as strings. I've now officially run out of things to implement in the code; perhaps I'll write a manual next (depending on the weather and enthusiasm on the weekend, and on Sven's willingness to accept texinfo). Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From sven at beta9.be Fri Jun 18 08:22:06 2004 From: sven at beta9.be (Sven Van Caekenberghe) Date: Fri, 18 Jun 2004 10:22:06 +0200 Subject: [s-xml-rpc-devel] Defining remote functions In-Reply-To: <10396097-C08B-11D8-8C76-000A959C96CC@free.fr> References: <10396097-C08B-11D8-8C76-000A959C96CC@free.fr> Message-ID: <95A46588-C100-11D8-906F-000A95B3E0D2@beta9.be> On 17 Jun 2004, at 20:20, Fr?d?ric Brunel wrote: > Hi, > > By googling the Web for an XML-RPC implementation in Common Lisp, I > found S-XML-RPC and other one for Corman Lisp. I'm glad that > S-XML-RPC is now part of Common-Lisp.net. > > By the way, looking at the Corman Lisp API for XML-RPC, I found > interesting that it have the ability to define a standard function > embedding an XML-RPC call. How about implementing this kind of thing > in S-XML-RPC? I wrote the following lines of code: > > (defmacro define-xmlrpc-method (name args &key url method) > `(defun ,name ,args > (xml-rpc-call (encode-xml-rpc-call ,method , at args) > :url ,(puri:uri-path url) > :host ,(puri:uri-host url) > :port ,(cond ((puri:uri-port url)) (t 80))))) > > (define-xmlrpc-method get-state-name (state) > :url #u"http://betty.userland.com/RPC2" > :method "examples.getStateName") > > (define-xmlrpc-method get-time () > :url #u"http://time.xmlrpc.com/RPC2" > :method "currentTime.getCurrentTime") > > ? (get-state-name 41) > "South Dakota" > > ? (get-time) > # > > I rely on the great PURI package to parse URL. Quite straightforward. 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. > 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. 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. > -- > Frederic Brunel Thanks for the feedback, frederic, Sven From sven at beta9.be Fri Jun 18 08:27:30 2004 From: sven at beta9.be (Sven Van Caekenberghe) Date: Fri, 18 Jun 2004 10:27:30 +0200 Subject: [s-xml-rpc-devel] New extensions In-Reply-To: References: Message-ID: <56A4A5A0-C101-11D8-906F-000A95B3E0D2@beta9.be> On 17 Jun 2004, at 21:51, Rudi Schlatte wrote: > Hi, > > I just checked in support for system.getCapabilities and added > standard error codes (I hope I didn't miss any places). The stuff > beyond the basic protocol now lives in extensions.lisp, and there are > some tests (not comprehensive at all, but it's a start). Lastly, it's > now possible to send symbols over the wire; they are encoded as > strings. Sounds great, I'll have a look later on. > I've now officially run out of things to implement in the code; > perhaps I'll write a manual next (depending on the weather and > enthusiasm on the weekend, and on Sven's willingness to accept > texinfo). Well, the more stuff we add, the more we need to document it, I have nothing against any format as long as there is an easy way to build the docs (I prefer make docs), with not too much dependencies. Sven From frederic.brunel at free.fr Mon Jun 21 22:46:18 2004 From: frederic.brunel at free.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Brunel?=) Date: Tue, 22 Jun 2004 00:46:18 +0200 Subject: [s-xml-rpc-devel] Defining remote functions In-Reply-To: <95A46588-C100-11D8-906F-000A95B3E0D2@beta9.be> References: <10396097-C08B-11D8-8C76-000A959C96CC@free.fr> <95A46588-C100-11D8-906F-000A95B3E0D2@beta9.be> Message-ID: > 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: