> 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 initial open standard (=RFC), we could later agree on extended versions of it. > > Possible problems I see in the current draft: > > * forbids XML entities, but "<" and ">" and "&" > > * forbids empty tags like <string/> > > I'm not sure I understand the point of these two things. It may be > difficult to comply with this because standard XML generating toolkits > out there might not be able to avoid them. The empty-tags-forbidden thing is, that simple token parsers (think of the flex tool) should also be able to read XML-RPC messages, but "<string/>" makes this more complicated than "<string></string>". And this is probably the most troublesome point I guess, because some of the toolkits may not be that configurable to output empty tags in the long form. (But then for implementors, this was just a simple string replacing effort afterwards). The current spec also tries to forbid using XML entities, other than the necessary replecements for < and > and &, because the not XML parser based XML-RPC libs are incapable of converting things like ⦃ or   back into UTF-8 chars. But as the draft already recommends UTF-8 strings throughout ALL messages, this seems a more little problem. And after all, the avoid-rules only apply to servers and only to their own output. But because most servers use XML parsers for the incoming messages I don't see much incompatibilites. The restricted-XML-syntax section in the current draft is merely only to support the simplistic clients. > From doing a couple of implementations of XML-RPC in a couple > different languages, I would like to think you for requiring <string> > tags around strings. That's always been a particularly annoying one to > parse for me. That thing made me also wondering a lot. ;-) > The struct definition seems a little odd. Do you not put tags around > the value (it's a little unclear)? It seems like requiring the name to > come before the value, but not having any requirement for the value > might make parsing a little harder (having many things to look for > rather than just one). I can't decide whether I like the naming > conventions on the name of the struct member. I'll go with a yes for > now. :) Not that you say, I'm unsure if I haven't forgotten something here. But for the "(value)" in there - this just refers to the earlier defined BNF syntax rule, which of course then again expands to something like "<value>(<int>...</int>)</value>". For sure the strange BNF syntax in RFCs makes everything more unreadable as if there were nicer examples all over; but that's an requirement for RFCs in general. > I think it might be good to separate the messaging from the transport. > One of the things that annoyed me was that XML-RPC required HTTP by > specification when the specification didn't really use HTTP for > anything in particular. Of the 635 XML-RPC methods I processed in the > last minute, none of them were over HTTP. Adam Megacz wrote a RFC draft earlier, called "XMC" then, which also contained various transports other than HTTP. Eventually this will come back, but I'd like the main document to discuss HTTP in more detail. So the other stuff would probably go into an appendix and only count as recommendations then; because I also think, that XML-RPC over SMTP won't ever be wideley utilized (asynchronous RPC is rather uncommon also). Also XMLRPC over Jabber would be a bit looser than than over HTTP (because it required to use namespaces for example), so this eventually also could go into its own RFC. Which also was a good thing, to advance this individually from the main RFC (a bit like separating it). > Oh, glancing through, I noticed you spelled ``Messages'' as > ``Massages.'' at one point. Was that intentional? :) Oooops, and I already fixed that several times ;) But really the draft is full of typing mistakes (not that interesting currently), and there are probably a lot of "q"'s typed all over (as I usually do)... But, thanks for the note! mario
