UserPreferences

XmlRpcDiscussion


Does this remain an OpenPoll?

The "votes" and discussion below are based on the previous name of this page "Don't use XML-RPC". (So -1 = don't not use XML-RPC, and +1 = use only not XML-RPC)

Phrased far too like an Irish referendum and explained far too like the explanation of an Irish referendum. Just so I remember when I come back here, -1 use xml-rpc, +1 don't use xml-rpc - BillDehora

[TomasJogin, RefactorOk, DeleteNotOk] Previous discussions concluded that the Necho format should actually be the bits on the wire, in both directions; both API and in syndication. I'm not entirely sure a consensus was reached on this matter, or even where they were held (here or at Sam's?) but if I'm not mistaking this is one of the key-features of Necho; that the input and output protocol are one and the same.

Yays

+1 BillDehora

+1 [DareObasanjo] An XML transfer format that doesn't understand XML namespaces or how to transfer elements with attributes is not suitable for use as a modern XML transfer format.

+1 [TimothyAppnel] The stated goals of this initative is to create a common syntax for syndication, archiving and a publishing API. SOAP (Document Literal encoding) and HTTP/REST would permit this type of common syntax reuse while XML-RPC would be a kludge at best.

+1 [ScottWatermasysk] KISS. Soap and Rest are enough. I am all for remembering the "roots", but at a certain point you have to cut some fat and just keep things simple.

+1 [TomasJogin] Soap and Rest are enough. XML-RPC support would be more of a liability than a feature.

+1 [MichaelManley] SOAPy and RESTful are qualities enough in an API.

+1 [MortenFrederiksen] XML-RPC has had its time...

+1 [MarkBaker] I don't want any RPC interface, be it XML-RPC or SOAP. Gimme a RESTful interface, optionally RESTful SOAP.

+1 [JimRoepcke] Just because the spec changed a couple days ago doesn't mean XML-RPC now has 78 toolkits that conform to the changes to the spec. See interop problems with UserLand's implementation here: http://blog.scriptdigital.com/index.php?entry=/Internet/Blogging/QuickLinks/quicklinks20030701.html. I would prefer a RESTful interface, but I feel for people like BrentSimmons that actually have to do the work!!! It seems a little early to decide on XML-RPC vs. SOAP, RPC vs. REST. The protocol shouldn't limit the API, so the API should be designed before the protocol is chosen. It would be worthwhile for someone to validate people's i18n concerns by testing the major toolkits before saying that XML-RPC isn't suitable, especially if many toolkits had been ignoring the ASCII limitation this whole time.

+1 [PatrickLioi] I didn't have a strong opinion until I saw this: http://diveintomark.org/archives/2003/07/08/on_simplicity.html REST is the clear choice. Why bother with something more complicated when the whole motivation here was to make something that is as easy as PIE.

+1 [DeveloperDude] a vote for SOAP/HTTP. SOAP/HTTP should be the suggested implementation. Implementations using GET-POST HTTP and XML-RPC are welcome.

+1 [ArveBersvendsen] My vote goes with REST. It keeps the barrier more than low enough for creating new tools and applications.

+1 [DeveloperDude] a vote for SOAP/HTTP. SOAP/HTTP should be the suggested implementation. Implementations using GET-POST HTTP and XML-RPC are welcome.

+1 [SimonFell] go REST, no toolkit required at all just a http client and xml parser. see RestLog for ideas.

+1 [DannyAyers] I had nothing against XML-RPC, I just thought it was a little past its sell-by date. My opinion has changed. The outcry from certain quarters against not using XML-RPC is such that it makes me think that there is a vendor-specific commercial/political agenda for maintaining the status quo. It looks like attempts are being made at a lock-in. So I now say sling XML-RPC!
Whatever, for the reasons above I certainly don't think it should be encouraged in the context of Necho, and I'd say keep it out of any normative documents. If a conflict appears between the XML style required by XML-RPC (see [WWW]Brent's comment) and the suggested (syndication output/API input) syntax sharing in the ProfileMatrix then XML-RPC can't be used anyway.

+1 [JeremyGray] Vote cast. Now, where to vote on REST or SOAP? And yes, for the sake of adoption I think it needs to be an "or" decision. At this point, though SOAP has benefits we could leverage long-term, it could become an "and" proposition when those benefits outweight the negatives of a) going SOAP and b) going with two mechanisms. I'll update the tally below, but just by adding my number to it. I'm not going to re-count it right now. :)

+1 [Arien] for REST.

+1 [[MikeDavies]] for REST or Tim Bray's WebAPI and formats that can handle DocumentLiteral formats

[SjoerdVisscher] I think we can use the general idea from the MetaWeblog API: apply a given set of rules to convert XML data to the XML-RPC model. The problem with the MetaWeblog API is that the XML data model isn't clear enough: If an element can occur more than once, the member in the struct has to contain an array. But it is not clear enough in RSS which items are allowed to occur more than once. Necho doesn't have this problem, because it has a schema. It would be very easy to create an XSLT that converts a Necho document into an XML-RPC document. It would even be doable to create an XSLT that converts the Necho schema to a Necho-to-XML-RPC XSLT.

+1 StevenCanfield Looking at the sheer difference in bytes sent for a message, I really like the non-XML-RPC option. People might even be able to hand code their feeds, which is an entirely desirable thing. I dislike that people would need a software program (unless they have obscene amounts of time on their hands) to generate Necho with XML-RPC. So yea, my vote is for XML.

+1 [JonDavis] for SOAP. If REST is chosen, we can make do, but either beats [WWW]XML-RPC (link to suggest I do understand XML-RPC).

Nays

-1 [GeorgBauer] XML/RPC is a very small and simple API with many benefits - if your application system doesn't provide it native, you can just hack up some support yourself. Actually mapping the EchoEntry to a dictionary to pass around is much simpler than to embed the direct EchoEntry into the request. So XML/RPC should be one alternative to call the API and there should be made a mapping. It should be a minor protocol, though, as others would map much better (especially the HTTP/REST stuff should map much nicer).

-1 [EmmanuelDecarie] I'm with Georg Bauer on this. Evan Williams think that there is already a consensus on this question. Is this true? [WWW]See here for reference.

-1 [GrantCarpenter] I think a version of the API for XML-RPC is necessary (in addition to RESTful and SOAP versions) for some semblance of backward compatability. Not direct 1:1 compatability per se, but many tools already communicate via XML-RPC and asking developers to adopt a new API and a new protocol at the same time increases barriers to adoption. I'm guessing it technically be done, and if that's the case, I think it should be done.

-1 [BrentSimmons] How much additional work do tool vendors need to do? XML-RPC is already what people use. Why change this too without *extremely* compelling reasons? Echo is already a new syndication format, archiving format, and editing API. To not use XML-RPC is to make it quite a bit harder to adopt.

-1 [DaveWiner] Brent got it right.

-1 [DanielBerlinger] I'm having the same response as Brent over on my [WWW]site.

-1 [MarkBernstein] Brent's [WWW]discussion of this issue is compelling -- so compelling that I'm inclined to believe that this is going to be the critical test for whether this project is serious. XML-RPC is clearly good enough for this task. It's easy. We're using it now. If you mandate SOAP, you *will* lose tools. If you mandate *three* protocols, weblog systems are going to implement just one -- and there goes your standard. Having read this page, top to bottom (7/2/03), I don't see that this is a close call.

-1 [JakeSavin] SOAP may not represent a huge barrier to entry for some developers, but IMO, it's at least an order of magnitude more complex than XML-RPC. I know this well, having put in a considerable amount of effort working on SOAP interop in 2001. The capabilities (and usability) of available SOAP toolkits may vary widely. As best I can tell, of the four reasons for not using XML-RPC noted above, the only one that's got any legs is the fact that XML-RPC dates don't specify a time-zone. All that would be required to address this is to stipulate that dates are expressed in GMT.

-1 [ThomasMadsenMygdal] Why abandon the simplicity that works and create a interface that's gonna create a huge barrier of entry for new developers. Simplicity works in the real world - allthough over-engineering is a common fad. And if there's no design requirement to use a more complex why bother - internalization is there, https support is there and making the time zone explisit is such a minor detail that using that as an argument is pretty absurd. SOAP is BigCo thinking creating a high barrier of entry for people trying to use the tools or creating tools. Nothing else.

-1 [CarlGarland] KISS while REST may be the simplest, XML-RPC is so much easier than SOAP. REST has its issues too in that some servers may have limits to the size of a headers post. I would wager that anything you can do in REST can be done easily in XML-RPC. As noted above only one of the 4 reasons above is at issue and that being the timezone which can be dealt with either by adding a field or using GMT, UTC

-1 [GaryF] XML-RPC is much simpler to use than SOAP, and it shouldn't be inherently limiting to the physical model.

-1 [BryantDurrell] See Jim Roepcke's comments above -- there's no need to make the decision at this time. I'm not saying "XML-RPC should be used." I'm saying "it's far too early to rule that protocol out."

-1 [DavidBrown] How hard is it, really, to support XML-RPC along with the the others? Doesn't really make sense to rule it out.

-1 [PeteProdoehl] As long as it's got REST, I don't care whether XML-RPC or SOAP is used. Ok, well, XML-RPC would probably be simpler...

-1 [Paolo Valdemarin] XML-RPC is the way to go. Given that so many tool vendors have already developed using XML-RPC, making their life simpler will give better chances to get PieApi implemented within apps that are already sitting on users' desktops.

-1 [PhillipPearson] Dropping XML-RPC support is just going to make life difficult for developers. The wire format doesn't need to be identical to the syndication format.

-1 [RichardTallent] REST and/or XML-RPC, SOAP should be optional. KISS principle. Blogging tool support will be key to FormerlyKnownAsEcho acceptance, and we won't get that by making tool developers have completely separate pipelines for RSS and FormerlyKnownAsEcho editing. At least the RSS/Echo content can theoretically be converted between each other with relatively simple XSLT.

-1 [RogerBenningfield] XML-RPC should be the default, with REST and SOAP optional alternatives. This whole process has been about finding our common ground, and when it comes to APIs, XML-RPC is our common ground.

-1 (James Robertson) - Supporting SOAP (or XML-RPC, or whatever) is pretty simple for me - I use Smalltalk, so in my world SOAP is actually simple. However, it's not simple everywhere - and the level of SOAP interop is about the same as CORBA was circa CORBA 1.0. So introduce SOAP if your goal is to make interop really difficult in the short term, and toolkit development (for most people) more difficult than necessary. why not something amazingly simple - use a form for posting, a servlet for dealing with said form, and a combination (if desired) of of HTTPS and HTTP authorization for security. Simple, anyone can implement it, it's supported by everything. To be brutal, I question the motivations of those who want to introduce SOAP. It smacks of classic "engineers disease" to me - i.e., "ooh, ahh, a new toy I haven't had a real chance to play with yet!"

-1 [DavidCzarnecki] - I'd like to see things start out with XML-RPC. Honestly I think it presents a very small barrier to entry for new developers and for seasoned blog developers who want to support this effort. For the past few years, the major blogging APIs (Blogger API, MetaWeblog API) have provided an interface through XML-RPC. I'm of the opinion that most people can crank out XML-RPC support for Echo quickly given that XML-RPC is so pervasive throughout the blogging community. This is a good thing. At the very least, it's a common ground.

-1 [TimSmith] The need for a single wire protocol is present. Dual-moded things like [LiveJournal] work because there's a single server that supports both. If, for some reason, other things started using the LJ protocol, and only used XML-RPC or only used the flat interface, confusion about which client to use would instantly spring up and clients would begin to be forced to support both in a single package for the sake of interoperability. Using more than one protocol would be an interoperability nightmare. That said. XML-RPC is here, it's stable, and it Works. SOAP is sort of here, not particularly stable, and doesn't particularly work under some platforms -- it's too complex. REST is very exciting looking, but it's new and doesn't have particularly wide support. I don't see any reason to not use XML-RPC at all, nor do I see much reason to not use REST.

-1 [pb] There should be only one and it seems early to pick. SOAP's fate still seems up in the air considering how unsimple it is. REST has bee horribly defined to date. XML-RPC is actually simple and in use. Proceed with XML-RPC until this shakes out.

-1 [DonPark] Don't be silly fellas. Use XML-RPC as the required binding and make SOAP and REST optional.

Abstensions

0 [AdriaanTijsseling] I'm on the fence on this one. I'm noting to many people for and too many people against. The debate is heated and I'm not so sure anymore if dropping XML-RPC support is a good idea. Does supporting XLM-RPC make any difference to the Echo conceptual framework? After all, the data is still the same, it's only wrapped differently. Perhaps the decision should be made by tool-developers.

0 [DiegoDoval AnswerMe] I'd like to make one note: I'd prefer it if the spec recommends a single wire protocol. Either SOAP, XML-RPC, or REST (Probably prefer REST though). I will use any of them, as far as I'm concerned the complexity of implementing them is pretty much the same (However, one of the ideas behind echo was to use the same input/output format, which XML-RPC usage would prevent). But I think that it has to be a single protocol, otherwise, we are going to implement the full API based on two (or worse, three) wire protocols, which would be a nightmare. Single wire protocol = interoperability from the start. Multiple wire protocols = even more work for tool developers.

Is there a rationale for why having multiple protocols does not create the problem of different tools supporting different systems (and therefore requiring that, at a minimum we also add a set of functions for "discovery", since I assume no one expects a user to input whether a server is REST or SOAP or whatever)?

0 [RahulDave] Exactly why are we trying to do anything more than specify an necho payload. Use direct-XML for REST, document encoding for SOAP, and MetaWeblog style structs for xmlrpc. I think this ought to be outside the scope of necho. Define the abstract structure of the message somehow just using the XML dtd/schema and leave the exact translation to followup individual groups instead of specializing it in a way which excludes. Please, please lets not overspecify. UPDATE: I think I misunderstood what the -1 was there, so I changed to a zero too. I want an API with all 3 approaches, but I'm like Tim here in wanting the Http API to be specified first. My reasoning is that there are two ways to implement SOAP and XML-RPC API's. All API's to one endpoint, or multiple endpoints and multiple functions. I do believe the two are not incompatible(parameter 1 in API may need translation from opaque endpoint to explicit one). Once we specify the http API we can agree (or disagree) on multiple SOAP or XML-RPC approaches..ultimately the tools market will decide for us.

0 [SimonPhipps] 'zero' because although I'm with Rahul on this one I'm not voting against anything. I think defining the payload first is the key, moving on to 'bindings' later. Any other approach will lead to divisive debates that distract from the key primary objective. The reason weblogs have become the most successful web services application to date is precisely because the focus has been on the content format rather than the connection mechanism and philosophy. I also agree with Sam that I'd like to see examples of the possible approaches prototyped before further voting.

0 [TimBray] I'm neither for nor against doing an interface in either XML-RPC or in SOAP. I probably wouldn't use such an API if there were a simpler pure-HTTP interface available, so I took a first whack at [WWW]sketching one out.

0 [AsbjornUlsberg] I agree with AdriaanTijsseling. What Echo becomes doesn't have to do anything with supporting XML-RPC or not, imho. We can model all we want, and not think of the protocol it's going to be transmitted over at all, until it's time for implementation. Then we may (but not must) have to rethink some parts of the model, but I doubt very hard that it will break anything important. So I say yay to support any framework available, and leave the implementation-bit up to the different Echo-feed providers. If they are demanded by their customers to deliver Echo over XML-RPC, then it's their job to do it.

Proposals

Representation first

Proposal: Let's first create an API in the REST Architectural Style. The SOAP and XML-RPC APIs can then easily be derived from that.

Requirements first

Proposal: Let's first create a list of API needs, then sketch versions of each in XML-RPC and REST.


[JeremyGray] I have removed my comment from the above section as the section has been refactored in such a way as to change the meaning of my comment there, which was only intended to show support for Sam's suggestion, not to cast a vote between two presented choices which are not actually reasonable alternates to one another. The headings say "representation first" vs. "requirements first" (which is not even an issue worth arguing - requirements come first, period) but the proposals imply a different choice: REST vs. XML-RPC & REST. If the headings and proposals can be brought in sync to explicitly present the choice between (post-requirements) initial representation via REST vs. XML-RPC & REST then I could cast an actual vote. Unless, of course, there is also an argument over requirements before representation, in which case I would suggest that we have far more fundamental issues that need to be covered before initial representation specifics :)


See also XmlRpc, RestAndRpc, SampleXmlrpc, [WWW]GoogleGenius


CategoryApi, CategoryInterop