From scaekenberghe at common-lisp.net  Wed Dec 21 15:58:10 2005
From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe)
Date: Wed, 21 Dec 2005 16:58:10 +0100
Subject: [s-xml-rpc-devel] Re: Bug in s-xml-rpc::encode-xml-rpc-call
In-Reply-To: <17320.54642.497689.481090@gargle.gargle.HOWL>
References: <17320.54642.497689.481090@gargle.gargle.HOWL>
Message-ID: <FEAF4AF7-45DA-4603-A492-027779B3FDDD@common-lisp.net>

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 at 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



From scaekenberghe at common-lisp.net  Fri Dec 23 09:02:14 2005
From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe)
Date: Fri, 23 Dec 2005 10:02:14 +0100
Subject: [s-xml-rpc-devel] Re: Bug in s-xml-rpc::encode-xml-rpc-call
In-Reply-To: <17321.54224.943204.880783@gargle.gargle.HOWL>
References: <17320.54642.497689.481090@gargle.gargle.HOWL>
	<FEAF4AF7-45DA-4603-A492-027779B3FDDD@common-lisp.net>
	<17321.54224.943204.880783@gargle.gargle.HOWL>
Message-ID: <8E62BE83-078F-4B84-935D-344230CABBFC@common-lisp.net>


On 21 Dec 2005, at 23:14, Alain.Picard at 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