Re: Larger than 32bit signed?

Hi All,

Just to add my humble view on this matter, I am both
against any change in the XML-RPC and against making a
new extended standard that would replace it. Here are
my reasons: 1 - that would defeat the purpose of
XML-RPC, and 2 - the present standard is sufficient.

1 - Once we start messing with the standard and
extending it, we will no longer have a simple, stable
standard for which it is easy to write compliant
client and servers. There will be no consensus what
extensions should be adopted and the standard will
fork to several standards. We would lose universal
interoperability. That would be hell. Besides, what if
I have a 32-bit machine that doesn't support 64-bit
numbers natively? Then I cannot have XML-RPC clients
or servers?

2 - You can implement long integers in the present
standard if you wish. Just don't encode them as i4,
but as base64. This slows things down because now a
conversion is required on both sides, but makes it
much more flexible. For example, sometimes you might
need numbers that are much larger that 64-bit -
applications in cryptography comes to mind.

Does this make sense?

Regards,

Aleksandar Janicijevic


--- [email protected] wrote:

> >The owner of the spec (Dave Winer) is loath to
> change it,
> 
> Dave isn't the owner of anything significant.  He
> controls one file on
> the Internet and possibly the name XML-RPC, but
> those aren't
> significant.
> 
> People with these proposals to extend XML-RPC speak
> as if their
> problems would be solved if Dave Winer would endorse
> the extension and
> change his file.  That would barely begin to solve
> any problem,
> because what needs to change is substantially all of
> the XML-RPC
> clients and servers in the world.  If you want
> interoperability, it
> doesn't matter that some document or person says a
> server _should_
> know what <i8> means.  What matters is if a client
> developer can
> expect it actually to do so.
> 
> "Changing" a spec means issuing a new spec.  The old
> one is still
> there and can still be referred to.  A code library
> that implements
> the original spec still implements it -- correctly. 
> Furthermore,
> issuing a new spec is nothing more than _proposing_
> different
> implementations.
> 
> Anyone can publish a new XML-RPC spec (probably
> using a different name
> for it) that has <i8>.  Dave Winer and xmlrpc.com
> notwithstanding.
> I know of several extensions to XML-RPC that have
> been published as
> standards, and several more that are invented by the
> various XML-RPC
> libraries.
> 
> Some specs occupy a world that is so dynamic that
> proposing more
> powerful implementations results in those
> implementations happening,
> and before long one can safely assume that one's
> communication
> partners implement the new spec.
> 
> I believe the issue with XML-RPC is that it is not
> in that world.  The
> culture of XML-RPC is one of light usage and
> development, so I
> personally would never expect enough servers to know
> <i8> that I would
> be comfortable making a client that needs it.  The
> <nil> extension is
> fairly widespread now, but I wouldn't rely even on
> that.
> 
> 
> (This isn't the only issue with extensions -- some
> people actually
> like the present simplicity of XML-RPC; I'm just
> trying to address the
> issue of whether there's a problem of the spec being
> frozen).
> 
> -- 
> Bryan Henderson                                   
> Phone 408-621-2000
> San Jose, California
> 
> 
>  
> Yahoo! Groups Links
> 
> 
>     [email protected]
> 
>  
> 
> 
> 



 
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/