Ryan Hoegg wrote:
> This all sounds like it adds a lot of complexity in order to extend the
> reach of XML-RPC. For me, the main problems with the spec as defined is
> the coupling with HTTP 1.0 and the lack of support for nulls. I'd like
> to see this in an RFC, but I think reaching out to le
Ken Gengler wrote:
> True, although the
Hello,
This all sounds like it adds a lot of complexity in order to extend the
reach of XML-RPC. For me, the main problems with the spec as defined is
the coupling with HTTP 1.0 and the lack of support for nulls. I'd like
to see this in an RFC, but I think reaching out to lexers instead of
f
On Jan 20, 2004, at 4:58 PM, Mario Salzer wrote:
But I see your point, and I think it would lead only
to a little slowdown to allow
> On Jan 20, 2004, at 15:31, Ken Gengler wrote:
>
> Part of the reason I wanted to use XML-RPC was that it was fairly
> efficient. Have the server run a "simple string replacing" effort on
> the output of an XML parser? The performance hit on any sizable
> document is going to be major. It means
On Jan 20, 2004, at 2:25 PM, Mario Salzer wrote:
... (But then for implementors, this was just a simple string
replacing effort afterwards).
I hope I'm misunderstanding you...
Part of the reason I wanted to use XML-RPC was that it was fairly
efficient. Have the server run a "simple string replac
> On Jan 20, 2004, at 13:49, Dustin Sallings wrote:
>
> > http://erfurtwiki.sourceforge.net/draft-xmlplusrpc-pre00.txt
>
> I like this, and I hope it gets some support. XML-RPC seems to be
> *almost* there, but dead for new changes.
Yep, that's the whole point. Only after we have an initia
On Jan 20, 2004, at 13:08, Mario Salzer wrote:
http://erfurtwiki.sourceforge.net/draft-xmlplusrpc-pre00.txt
I like this, and I hope it gets some support. XML-RPC seems to be
*almost* there, but dead for new changes.
Possible problems I see in the current draft:
* forbids XML entities, but "<"
