s-xml-rpc-devel

s-xml-rpc-devel@common-lisp.net

21 discussions

[s-xml-rpc-devel] Fault returned when calling method with no arguments
by Andrew Jones-Gonzales 14 Oct '08

14 Oct '08

I've run into an interesting problem where S-XML-RPC would complain that an "empty" string was not of type LIST. It would only occur when I used S-XML-RPC for just the server. When I used something else as the client, like the command line tool that came with the XML-RPC-C library or the XML-RPC.Net library for C#, the server would return the fault. Using S-XML-RPC as a client worked fine. After some debugging, I think I traced the cause to a few extra #\Newline and #\Return characters getting inserted into the XML from these other libraries/tools. So essentially, they give us a string that should be empty, but instead has whitespace in it. I'm not sure if it's more correct to patch these other libraries instead, but the small patch I'm attaching fixes this in S-XML-RPC. Cheers, -Andrew Jones-Gonzales

1 0

[s-xml-rpc-devel] [PATCH] Interoperability issue with WS-XMLRPC
by Daniel Janus 18 Apr '08

18 Apr '08

Hello, I'm using the current asdf-installable version of S-XML-RPC with SBCL 1.0.15 (hand-compiled from source on an i686) and have been trying to connect with its client API to various XML-RPC servers. It has been mostly working, with only an exception of one server. The server in question is an enterprise Java EE 5 application, written using Apache WS-XMLRPC library (version 3.1 to be more precise) and deployed on a cluster consisting of two Glassfish enterprise server instances, both running on Ubuntu 6.06.1. The problem manifests itself in XML-RPC-CALL -- it bails out with an error "no response from server". I tried another XML-RPC stack (the one that comes with Python) and I had no problems with making the same request to the same server. I did some preliminary investigation and found a workaround to the problem. It seems that building up the whole XML-RPC request beforehand, then sending it all at once (rather than FORMATting the HTTP headers to the TCP stream one-by-one) fixes the problem. This is what the attached patch does. I enclose it just in case someone else runs into the same problem; it works for me, on the downside, it probably causes the library to do more consing, although I did not check that empirically. Strangely enough, the problem does not seem to occur with an installation of the very same Java application on a single (non-clustered) Glassfish running on newer versions of Ubuntu. Clearly, more detailed investigation is required. As soon as I have time for that, I will attempt to reproduce the behaviour on various setups and using various Lisps (I have access to Allegro 8.1), to see where the problem really lies. I hope for attaining a true fix instead of a workaround. I will send a followup as soon as I have more detailed information. Best, -- Daniel Janus <daniel(a)sentivision.com> Senior Software Engineer, SENTIVISION Mb: +48.501180396 | Ph: +48.226400860

2 1

[s-xml-rpc-devel] significant speed increase in SBCL
by William Halliburton 17 Feb '08

17 Feb '08

Hello all. Using s-xml-rpc with SBCL 1.0.14 and was seeing a lot of consing. Just attempted to hit some low hanging fruit and got lucky. Please excuse any wierd table cut-and-paste formatting below. I am using hunchentoot as the front end and was calling as such: (handle-xml-rpc-call (raw-post-data :want-stream t) id) Profiling gave: (note that the lisp test system was calling itself so both the call and answer are shown, but I really only care about the answer.) ;; seconds | consed | calls | sec/call | name ;; ---------------------------------------------------------- ;; 10.430 | 107,109,496 | 32 | 0.325942 | S-XML-RPC:XML-RPC-CALL ;; 5.583 | 57,897,032 | 1,670 | 0.003343 | S-XML::PARSE-IDENTIFIER ;; 1.179 | 12,740,176 | 835 | 0.001412 | S-XML::PARSE-XML-ELEMENT ;; 1.073 | 9,625,512 | 1,845 | 0.000582 | S-XML::PARSE-WHITESPACE ;; 0.988 | 8,591,704 | 239 | 0.004132 | S-XML::PARSE-TEXT ;; 0.425 | 4,491,216 | 899 | 0.000472 | S-XML::SKIP-WHITESPACE ;; 0.111 | 53,968 | 1,670 | 0.000067 | S-XML:RESOLVE-IDENTIFIER ;; 0.041 | 0 | 11,810 | 0.000003 | S-XML::IDENTIFIER-CHAR-P ;; 0.028 | 516,088 | 64 | 0.000436 | S-XML-RPC::FORMAT-HEADER ;; 0.021 | 720 | 1,670 | 0.000013 | S-XML::FIND-NAMESPACE-BINDING ;; 0.021 | 0 | 1,845 | 0.000011 | S-XML::GET-BUFFER ;; 0.013 | 0 | 1,670 | 0.000008 | S-XML:SPLIT-IDENTIFIER ;; 0.011 | 0 | 835 | 0.000013 | S-XML-RPC::DECODE-XML-RPC-FINISH-ELEMENT When I changed handle-xml-rpc-call to take a string as make its own stream as such: (handle-xml-rpc-call-string (raw-post-data) id) (defun handle-xml-rpc-call-string (string id) (with-input-from-string (in string) (let ((call (decode-xml-rpc in))) (let ((result (apply *xml-rpc-call-hook* (first call) (rest call)))) (encode-xml-rpc-result result)))))) I now profile: seconds | consed | calls | sec/call | name --------------------------------------------------------- 0.985 | 15,135,160 | 32 | 0.030786 | S-XML-RPC:XML-RPC-CALL 0.023 | 118,296 | 1,670 | 0.000014 | S-XML:RESOLVE-IDENTIFIER 0.021 | 0 | 11,810 | 0.000002 | S-XML::IDENTIFIER-CHAR-P 0.019 | 769,856 | 32 | 0.000593 | RPC-HANDLER 0.016 | 459,688 | 64 | 0.000248 | S-XML-RPC::FORMAT-HEADER 0.013 | 11,128 | 899 | 0.000014 | S-XML::SKIP-WHITESPACE 0.010 | 12,536 | 1,670 | 0.000006 | S-XML::PARSE-IDENTIFIER 0.009 | 0 | 1,670 | 0.000006 | S-XML::GET-MINI-BUFFER 0.009 | 0 | 1,670 | 0.000006 | S-XML:SPLIT-IDENTIFIER 0.004 | 0 | 8 | 0.000498 | UPDATE-SEARCH-STRING 0.004 | 7,944 | 32 | 0.000118 | S-XML-RPC::ENCODE-XML-RPC-RESULT For a 10 fold speed increase. I just thought this might be of use to someone down the line. Will

2 1

[s-xml-rpc-devel] BUG ?
by Evgeniy Zamriy 15 Feb '08

15 Feb '08

Hello, All. Version of SBCL - 1.0.1 Version of s-xml-rpc - latest from cvs I found possible bug in library: * (decode-xml-rpc (make-string-input-stream "<value><boolean>1</boolean></value>")) * T * (decode-xml-rpc (make-string-input-stream "<value><boolean>0</boolean></value>")) * "" So, when my client resieves "false" from server I get "" except of nil. Is this bug or feature ? :) I tryed to fix it, but my experience in lisp isn't well. P.S.: my english is bad, sorry :) -- Best regards, Evgeniy Zamriy

2 2

[s-xml-rpc-devel] loss of precision on double
by Jeff Sapp 15 Feb '08

15 Feb '08

Hey, I was using s-xml-rpc to receive some double values and I noticed that was losing precision on them. I looked a bit closer and I noticed that the function decode-xml-rpc-new-element was reading in doubles with read-from-string which has a default return type of single-float. I'd still consider myself new at this lisp business, so my fix probably isn't stellar. I've also run into some performance issues and I was wondering if anyone had some advice. The function I'm having particular trouble with returns a list of lists, where the outside list is about 20k elements long, and the inside lists around no larger than 20. It takes about two minutes to encode the whole thing. If you had to make the encoding more efficient, where would you start? Thanks, ~jeff

2 2

[s-xml-rpc-devel] s-xml-rpc simple problem.
by Nicolas Lamirault 18 Feb '07

18 Feb '07

hello, i try to use s-xml-rpc to test the Gandi XML RPC API. In python, there is an example code : import sys import xmlrpclib proxy = xmlrpclib.ServerProxy("https://api.ote.gandi.net/xmlrpc/") try: session = proxy.login("AA1234-GANDI", "mypassword") except xmlrpclib.Fault, e: print "could not login because: " + e.faultString sys.exit(67) it is possible to make this call with s-xml-rpc ? Thanks for any help.

1 0

[s-xml-rpc-devel] SBCL support
by Sebastián González 01 Nov '06

01 Nov '06

Hi there, When I tried the following code from the "test" directory of s-xml-rpc, using SBCL, I got an error: (assert (let ((server-process (start-xml-rpc-server :port 8080))) (import 's-xml-rpc::xml-rpc-implementation-version :s-xml-rpc-exports) (sleep 1) ; give the server some time to come up ;-) (unwind-protect (equal (xml-rpc-call (encode-xml-rpc-call "XML-RPC-IMPLEMENTATION-VERSION") :port 8080) (xml-rpc-implementation-version)) (s-sysdeps:kill-process server-process) (unintern 's-xml-rpc::xml-rpc-implementation-version :s-xml-rpc-exports)))) The error message is the following (copy-pasted from Slime): The value (("xml-rpc server /RPC2:8080" #<SB-BSD-SOCKETS:INET-SOCKET descriptor 4 {B61F4C9}> #<SB-IMPL::HANDLER INPUT on descriptor 4: #>)) is not of type SB-THREAD:THREAD. [Condition of type TYPE-ERROR] Apparently SBCL's implementation of s-sysdeps:start-standard-server is broken... Does this code still have a maintainer? should I fix it myself and submit a patch? Thanks, Sebastián

1 0

[s-xml-rpc-devel] Patch
by Maciek Pasternacki 27 Aug '06

27 Aug '06

Hello. I started to look at s-xml-rpc library today and to communicate with Python client. Python's default xmlrpclib sends no-argument methods like this (from debug log): ,---- | <?xml version='1.0'?> | <methodCall> | <methodName>system.listMethods</methodName> | <params> | </params> | </methodCall>12 received call ("system.listMethods" . " | ") `---- Library throws error from #'APPLY because last argument is a string, not a list. A simple patch that makes it work: #v+ diff -u xml-rpc{-orig,}.lisp --- xml-rpc-orig.lisp 2006-08-27 21:43:19.000000000 +0200 +++ xml-rpc.lisp 2006-08-27 21:43:25.000000000 +0200 @@ -494,6 +494,8 @@ ;; -32603 ---> server error. internal xml-rpc error (encode-xml-rpc-fault (format nil "~a" c) -32603))))) (let ((call (decode-xml-rpc (debug-stream in)))) + (unless (listp (rest call)) + (setf (rest call) nil)) (format-debug (or *xml-rpc-debug-stream* t) "~a received call ~s~%" id call) (let ((result (apply *xml-rpc-call-hook* (first call) #v- -- __ Maciek Pasternacki <maciekp(a)japhy.fnord.org> [ http://japhy.fnord.org/ ] `| _ |_\ / { Ibi nullus timet mortem ,|{-}|}| }\/ sed pro Baccho mittunt sortem. } \/ |____/ ( Carmina Burana ) -><-

1 0

[s-xml-rpc-devel] bug: S-XML-RPC sends unencoded strings with invalid characters
by Taylor R Campbell 28 Jul '06

28 Jul '06

Well-formed XML is not allowed to include character entities that are not legal XML characters, according to the definition of character entity references in section 4.1 of the XML 1.0 specification: [66] CharRef ::= '&#' [0-9]+ ';' | '&#x' [0-9a-fA-F]+ ';' Well-formedness constraint: Legal Character - Characters referred to using character references MUST match the - production for Char. The production for Char is defined in section 2.2: [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] Strings with any other characters ought to be base64-encoded. I just encountered a problem when lisppaste sent an XML-RPC response with a paste that contains form feed characters to client with an extremely strict XML parser.

2 4

[s-xml-rpc-devel] Re: Incorrect decoding of XML RPC messages
by Sven Van Caekenberghe 19 Apr '06

19 Apr '06

On 18 Apr 2006, at 06:56, Alain Picard wrote: > Okay -- I've got a fix which ensures that things > like "<data> </data>" decode as NIL, instead of " ". > > Here are the diffs, in case you want to have a look > and/or fold them in. > > > The gist of it now is that if you're inside a <value>, > you always get a string if the inner type is not specified, > since the spec says: > "If no type is indicated, the type is string." > > Thus "<value></value>" now decodes as "". > > I also fixed what I think is a bug in that > (encode-xml-rpc-value T) ==> "T" instead of <boolean>1</boolean>. > (same for NIL). > > <diff> Alain, I tried to integrate your changes; I didn't take over the special variable: it felt less elegant and I think I managed to solve all your problems without it. I took over most of your code though: thanks! I added a number of extra test cases to test-xml-rpc.lisp to cover all the problems that you reported. Have a look at it and tell me if this works for you. This is the official change log entry (all changes were commit but not yet released as tarball): * changes due to reporting and initial fixes by Alain Picard * added support for whitespace handling * iso8601->universal-time now accepts leading & trailing whitespace * encode-xml-rpc-value now encodes t and nil correctly as boolean 1 and 0 * parsing doubles (using read-from-string) with reader macros disabled for security * decode-xml-rpc now handles whitespace more correctly in <data> and <value> tags * added several test cases and fixed older stop-server problem I enclosed a context diff here for your convenience. Sven

1 0

[s-xml-rpc-devel] Re: [(nowhere)] Incorrect decoding of XML RPC messages
by Sven Van Caekenberghe 14 Apr '06

14 Apr '06

Alain, On 14 Apr 2006, at 07:32, Alain Picard wrote: > Once upon a time (release 6, Januari 21, 2004) xml-rpc used to decode > messages thusly: > > XML-RPC> (decode-xml-rpc (make-string-input-stream > "<value> > <array> > <data> > </data> > </array> > </value>")) > NIL > XML-RPC> > > But now (2004-06-17 Rudi Schlatte <rudi(a)constantly.at>), > it does it this way: > S-XML-RPC> (decode-xml-rpc (make-string-input-stream > "<value> > <array> > <data> > </data> > </array> > </value>")) > " > " > > Which I think is COMPLETELY wrong. > > Whereas > S-XML-RPC> (decode-xml-rpc (make-string-input-stream > "<value><array><data></data></array></value>")) > NIL > > Is still OK. > > So I think something is wrong with the parser. The handling of whitespace (or the significance of whitespace) in XML and especially in between elements is tricky. I know that it is allowed and sometimes significant. So I would say that it depends upon the XML application, in this case XML-RPC. The XML-RPC spec is not superclear about all this. But what is clear is that a <data> element can only contain <value> elements and nothing else. So the simplest change that I could make to fix your testcase would be: [sven@voyager:~/apps/clnet/s-xml-rpc/s-xml-rpc]$ cvs diff src/xml- rpc.lisp Index: src/xml-rpc.lisp =================================================================== RCS file: /project/s-xml-rpc/cvsroot/s-xml-rpc/src/xml-rpc.lisp,v retrieving revision 1.8 diff -r1.8 xml-rpc.lisp 281c281 < (:|data| (nreverse seed)) --- > (:|data| (unless (stringp seed) (nreverse seed))) (I did not yet check this in). This change comes down to the following: before, any subelements (including text and/or whitespace) of <data> were accepted as is; now, all text (whitespace or not) as subelement of <data> are ignored. Does this work for you ? Does anybody else have any opinion about this ? Sven -- Sven Van Caekenberghe - mailto:sven@beta9.be Beta Nine - software engineering - http://www.beta9.be .Mac - svc(a)mac.com - http://homepage.mac.com/svc "Lisp isn't a language, it's a building material." - Alan Kay

1 0

[s-xml-rpc-devel] Question about server functions
by Peter Hertmuller 16 Feb '06

16 Feb '06

Hi everybody I'm trying to use the s-xml-rpc stuff to communicate a couple of applications. One of them offers several capabilities required by the others. My question is what I have to do to make available the functionalities of my server? The system has over 100 functions (including macros, variables) and I don't know if what I can do is to extend the s-xml-rpc-exports package with these functions. I don't have so much idea about the packaging system in lisp. I'm using SBCL 0.9.4. Any help is welcome. Thanks in advance for your time Peter

1 0

[s-xml-rpc-devel] S-BASE64 & S-SYSDEPS
by Sven Van Caekenberghe 09 Jan '06

09 Jan '06

From now on, the local sydeps.lisp file is replace by a dependency on the more general S-SYSDEPS package ( http://homepage.mac.com/svc/s- sysdeps/ ) and the local base64.lisp is replaced by a dependency on the equivalent S-BASE64 package ( http://homepage.mac.com/svc/s- base64/ ). Only in CVS HEAD for now, if there are no objections, I will release this soon to the tarballs. Later, I intend to start using both S-HTTP-CLIENT as well as S-HTTP- SERVER to even further simplify the S-XML-RPC code base and to maximize reuse over my open source common lisp packages. Sven

1 0

[s-xml-rpc-devel] Re: Bug in s-xml-rpc::encode-xml-rpc-call
by Sven Van Caekenberghe 23 Dec '05

23 Dec '05

On 21 Dec 2005, at 23:14, Alain.Picard(a)memetrics.com wrote: > Sven Van Caekenberghe writes: >> Alain, >> >> If I understand your fix correctly, you want to interpret NIL >> immediately as an empty array. >> Before, NIL was interpreted as a boolean, no ? >> What would be best ? >> In CL, this very convenient fact (false == empty list) is a problem >> when you want auto typing of arguments. > > Ah, darn, yes, I forgot that it was pulling double duty as a boolean. > > I did this without much tought, because what happened is that a > test I had which used to run stopped running when I went from > xml-rpc to s-xml-rpc, so I quickly discovered interpreting NIL > as a symbol as the culprit. Now I'm not so sure. > > Barring an "official" type mapping between lisp and XMLRPC, > I guess it gets down to you to choose (and to document your choice). > > I think losing NIL as a boolean is too costly a price to pay, > so perhaps forcing user code to use empty arrays instead of empty > lists is an acceptable price to pay. > > So users would have to write code like this > (s-xml-rpc:encode-rpc-call "method" ... (or foo #()) ... ) > > which sucks, but, if they don't like it, they can use vectors > instead of lists as the data type for foo. > > Other marshalling systems, e.g. CORBA, don't have these issues > as they need to declare types up front as part of the method > signature. > > OK, well, thanks for reminding me of the true nature of the problem. > Perhaps the best thing is to simply leave it as is. OK, unless there are others with a different opinion, we will leave it at that for now, the mailing list archive will keep a reference of this issue for future reference. Sven

1 0

[s-xml-rpc-devel] Re: Bug in s-xml-rpc::encode-xml-rpc-call
by Sven Van Caekenberghe 21 Dec '05

21 Dec '05

Alain, If I understand your fix correctly, you want to interpret NIL immediately as an empty array. Before, NIL was interpreted as a boolean, no ? What would be best ? In CL, this very convenient fact (false == empty list) is a problem when you want auto typing of arguments. Any other opinions ? Sven On 21 Dec 2005, at 05:09, Alain.Picard(a)memetrics.com wrote: > Hi Sven! > >> I note that empty arrays and empty lists are not treated >> similarly, to wit: > > This definition of encode-xml-rpc-value > fixes the problem I just reported: > > (defun encode-xml-rpc-value (arg stream) > (write-string "<value>" stream) > (cond ((null arg) > (encode-xml-rpc-array arg stream)) > ((or (stringp arg) (symbolp arg)) > (write-string "<string>" stream) > (print-string-xml (string arg) stream) > (write-string "</string>" stream)) > ((integerp arg) (format stream "<int>~d</int>" arg)) > ((floatp arg) (format stream "<double>~f</double>" arg)) > ((or (null arg) (eq arg t)) > (write-string "<boolean>" stream) > (write-string (if arg 1 0) stream) > (write-string "</boolean>" stream)) > ((and (arrayp arg) > (= (array-rank arg) 1) > (subtypep (array-element-type arg) > '(unsigned-byte 8))) > (write-string "<base64>" stream) > (encode-base64-bytes arg stream) > (write-string "</base64>" stream)) > ((xml-rpc-time-p arg) > (write-string "<dateTime.iso8601>" stream) > (universal-time->iso8601 (xml-rpc-time-universal-time arg) stream) > (write-string "</dateTime.iso8601>" stream)) > ((xml-literal-p arg) > (write-string (xml-literal-content arg) stream)) > ((or (listp arg) (vectorp arg)) (encode-xml-rpc-array arg stream)) > ((xml-rpc-struct-p arg) (encode-xml-rpc-struct arg stream)) > ;; add generic method call > (t (error "cannot encode ~s" arg))) > (write-string "</value>" stream)) > > Cheers, > --ap

1 0

[s-xml-rpc-devel] cmucl port
by Fred Nicolier 04 Nov '05

04 Nov '05

Hi, I wrote some lines to port s-xml-rpc to cmucl. Here is the code from the file sysdeps.lisp : What do you think? >> ;;;; -*- mode: lisp -*- ;;;; ;;;; $Id: sysdeps.lisp,v 1.1.1.1 2004/06/09 09:02:39 scaekenberghe Exp $ ;;;; ;;;; These are the system dependent part of S-XML-RPC. ;;;; Ports to OpenMCL, LispWorks and SBCL are provided. ;;;; Porting to another CL requires implementating these definitions. ;;;; ;;;; Copyright (C) 2002, 2004 Sven Van Caekenberghe, Beta Nine BVBA. ;;;; SBCL port Copyright (C) 2004, Brian Mastenbrook & Rudi Schlatte. ;;;; ;;;; You are granted the rights to distribute and use this software ;;;; as governed by the terms of the Lisp Lesser General Public License ;;;; (http://opensource.franz.com/preamble.html), also known as the LLGPL. (eval-when (compile load eval) #+cmu (require :simple-streams)) (in-package :s-xml-rpc) (defmacro with-open-socket-stream ((var host port) &body body) "Execute body with a bidirectional socket stream opened to host:port" #+openmcl `(ccl:with-open-socket (,var :remote-host ,host :remote-port ,port) ,@body) #+lispworks `(with-open-stream (,var (comm:open-tcp-stream ,host ,port)) ,@body) #+cmu `(let ((,var (make-instance 'stream:socket-simple-stream :direction :io :remote-host ,host :remote-port ,port))) (unwind-protect (progn ,@body) (ext:close-socket ,var))) #+sbcl (let ((socket-object (gensym))) `(let ((,socket-object (make-instance 'sb-bsd-sockets:inet-socket :type :stream :protocol :tcp))) (sb-bsd-sockets:socket-connect ,socket-object (car (sb-bsd-sockets:host-ent-addresses (sb-bsd-sockets:get-host-by-name ,host))) ,port) (let ((,var (sb-bsd-sockets:socket-make-stream ,socket-object :element-type 'character :input t :output t :buffering :none))) (unwind-protect (progn ,@body) (close ,var)))))) (defun run-process (name function &rest arguments) "Create and run a new process with name, executing function on arguments" #+lispworks (apply #'mp:process-run-function name '(:priority 3) function arguments) #+openmcl (apply #'ccl:process-run-function name function arguments) #+sbcl (apply function arguments) #+cmu (apply function arguments)) (defvar *server-processes* nil) (defun start-standard-server (&key port name connection-handler) "Start a server process with name, listening on port, delegating to connection-handler with stream as argument" #+lispworks (comm:start-up-server :function #'(lambda (socket-handle) (let ((client-stream (make-instance 'comm:socket-stream :socket socket-handle :direction :io :element-type 'base-char))) (funcall connection-handler client-stream))) :service port :announce t :error t :wait t :process-name name) #+openmcl (ccl:process-run-function name #'(lambda () (let ((server-socket (ccl:make-socket :connect :passive :local-port port :reuse-address t))) (unwind-protect (loop (let ((client-stream (ccl:accept-connection server-socket))) (funcall connection-handler client-stream))) (close server-socket))))) #+cmu (let* ((socket (ext:create-inet-listener (or port 0))) (handler-fn (lambda (fd) (declare (ignore fd)) (let ((stream (sys:make-fd-stream (ext:accept-tcp-connection socket) :buffering :none :input t :output t :element-type 'base-char))) (funcall connection-handler stream))))) (push (list name socket (sys:add-fd-handler socket :input handler-fn)) *server-processes*)) #+sbcl (let* ((socket (make-instance 'sb-bsd-sockets:inet-socket :type :stream :protocol :tcp)) (handler-fn (lambda (fd) (declare (ignore fd)) (let ((stream (sb-bsd-sockets:socket-make-stream (sb-bsd-sockets:socket-accept socket) :element-type 'character :input t :output t :buffering :none))) (funcall connection-handler stream))))) (setf (sb-bsd-sockets:sockopt-reuse-address socket) t) (sb-bsd-sockets:socket-bind socket #(0 0 0 0) port) (sb-bsd-sockets:socket-listen socket 15) (push (list name socket (sb-sys:add-fd-handler (sb-bsd-sockets:socket-file-descriptor socket) :input handler-fn)) *server-processes*)) name) (defun stop-server (name) "Kill a server process by name (as started by start-standard-server)" #+lispworks (let ((server-process (mp:find-process-from-name name))) (when server-process (mp:process-kill server-process))) #+openmcl (let ((server-process (find name (ccl:all-processes) :key #'ccl:process-name :test #'string-equal))) (when server-process (ccl:process-kill server-process))) #+sbcl (progn (destructuring-bind (name socket handler) (assoc name *server-processes* :test #'string=) (sb-sys:remove-fd-handler handler) (sb-bsd-sockets:socket-close socket)) (setf *server-processes* (delete name *server-processes* :key #'car :test #'string=))) #+cmu (progn (destructuring-bind (name socket handler) (assoc name *server-processes* :test #'string=) (sys:remove-fd-handler handler) (ext::close-socket socket)) (setf *server-processes* (delete name *server-processes* :key #'car :test #'string=))) name) ;;;; eof >> -- Fred Nicolier

2 1

[s-xml-rpc-devel] Port to cmucl + accidental breakage
by Rudi Schlatte 26 Oct '04

26 Oct '04

Hi, I've just checked in cmucl support for s-xml-rpc. In the process, I seem to have deleted allegro support (I wasn't on my development machine, so started from the latest asdf-installable version and didn't diff before committing from my main machine). I'll go restore allegro support now. Rudi

1 0

[s-xml-rpc-devel] Defining remote functions
by Frédéric Brunel 08 Jul '04

08 Jul '04

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 ,@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) #<XML-RPC-TIME 20040617T10:47:31> 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

2 3

[s-xml-rpc-devel] New extensions
by Rudi Schlatte 18 Jun '04

18 Jun '04

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

2 1

[s-xml-rpc-devel] system.multicall implemented
by Rudi Schlatte 13 Jun '04

13 Jun '04

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

1 0

[s-xml-rpc-devel] Added some introspection
by Rudi Schlatte 13 Jun '04

13 Jun '04

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

s-xml-rpc-devel