Re: Larger than 32bit signed?

Wow. Quite a spirited debate thus far. I've waited before chiming in,
because I've had actual person-to-person clashes with Dave Winer over these
issues. I don't know if he's still reading, and I don't particularly want to
argue with him any more than I have in the past. But as an author of an
XML-RPC toolkit (the RPC::XML module for Perl), I have first-hand experience
with this.

In my opinion, a specification that has no room for evolution and growth
will stagnate. It will be replaced by something that does have that room and
potential, because people want to feel like they can tackle new problems as
they come up. Many have said that the current XML-RPC spec cannot be
modified because it would leave existing implementations in a state of flux.
I say this is a misleading argument-- the W3C itself has accepted that
sometimes in the process of revising and cleaning up a spec, you will have
problems with backwards-compatibility. There are breaks between WSDL and
WSDL2, XHTML does more than just require tags like <p> be closed-- and so
on.

It is my belief that XML-RPC could be brought to a more-complete state
through a carefully-considered review of the specification, and through
clearly-defined standards for compliant implementations. I think that the
addition of a "version" attribute to the <methodCall> and <methodResponse>
tags could be used by both client and server code to distinguish a "new"
versus "old" message. If you make the "version" attr required in the new
version (call it 2, for argument's sake), then by definition a compliant
message will either carry it (and be version 2) or not (and thus be version
1). If it had version 2 features but no "version", then it's isn't a valid
message in the first place and throwing a fault is perfectly reasonable.

Is it more work for us developers? Of course it is. You expect that when an
established spec is being updated. Think about what the developers of the
Gecko rendering engine used by Mozilla and Firefox have to go through,
dealing with all the broken variants of HTML, as well as XHTML. None of this
would approach that level of complexity. But it *can be done*. And the first
step is getting someone in charge of the spec who is committed to following
the process through to completion. Dave has chosen to move on to other
things, and leave XML-RPC gathering dust. I wish he would step aside and let
someone move XML-RPC beyond 1999.

Randy
--
Randy J. Ray / [email protected]
Campbell, CA


[Non-text portions of this message have been removed]



 
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/