Re: Larger than 32bit signed?

Hi.

Although I was suprised at first by the seeming inflexibility of the  
spec's author, I eventually came to admire the assertions:

  - any-one can write a spec that amounts to XML-RPC with extensions (just  
don't
    CALL it XML-RPC).
  - If enough people get enough real benefit out of the extensions it will  
gather
    market share, mind share, conformant implementations, etc. or at least  
aclaim!!

Some poeple would argue that that is what SOAP is.  Other people would  
argue that XML-RPC is perfect.  But seriously, if you think you have a  
better way to do it, nothing is stopping you!  Let us know on the list  
when you have the spec written!!

----------------->Nathan

On Fri, 10 Feb 2006 08:10:00 -0800, Mark Ellzey <[email protected]> wrote:

> On 10 Feb 2006 07:15:02 +0000, [email protected]
> <[email protected]> wrote:
>> >> I don't think the lack of protocol version information makes much
>> >> difference in this case.
>> >Maybe I am overlooking something but the underlying API's would have a
>> >chance to fall back to earlier versions and do some of the hacky
>> >conversions described in this thread.
>>
>> What I'm thinking is that if you can write a program that falls back
>> to the 1999 standard, then you might as well do _just_ the 1999
>> standard.
>>
>> In other protoocols, there are cases where a multi-protocol
>> communicant is able to work more efficiently with a new protocol but
>> fall back to an older one when working with an old partner, but I
>> don't see anything like that in new XML-RPC data types.
>>
>> The advantage of new data types would be that it's easier to write
>> (and test, debug, and maintain) code.  If you have to additionally
>> write the difficult fallback code, that ruins everything.  And if you
>> don't write the fallback code, you have the interoperability problem
>> where you have to worry about whether the particular client or server
>> you want to talk to knows the newer protocol.
>>
>
> XML-RPC was built for simplicity as stated many times in this thread,
> it was certainly not built to scale. I don't think the developer using
> xml-rpc libs should be punished because nobody wants to change
> anything ever.
>
> The thing that has suprised me most about the replies here are the
> preconceptions of this being  hard for everyone and everything. The
> addition of common data types does not turn this simple transport
> method linto asn.1 and it does not change the protocol completely.This
> would be an addition not a redesign. If there are incompatibilities
> with versions that are above you, then so be it. In growth comes
> incompatibilities.
>
> The above point is moot anyway since there is no way of telling what
> version of the protocol one is using.
>
>
> Yahoo! Groups Links
>
>
>
>
>
>



-- 





---
(([^/]+)/([^/]+)){0,1}/*(([^/]+)/([^/]+)){0,1}/*(([^/]+)/([^/]+)){0,1}/*
(([^/]+)/([^/]+)){0,1}/*(([^/]+)/([^/]+)){0,1}/*(([^/]+)/([^/]+)){0,1}/*
---



Nathan Young
N. C. Young Design
(530)629-4176
http://ncyoung.com


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/