intertwingly

Sam Ruby continues his "patient evangelism" and has released a new essay entitled Evolution of the Weblog APIs. Its black and white arguments like these that made me lose favor with XML-RPC and the like and develop RESTful leanings. It puzzles me that anyone can still insist that XML-RPC is somehow simpler or better suited.... [more]

Trackback from tima thinking outloud.

I don't see a question.

Here's a specific question dealing with a core element which has been present since RSS 0.92: how do you make a metaWeblog.newPost request if the blog entry is in two categories?

Thanks for a clear question (of course the metaweblog API came way after 0.92, but I guess that's a quibble). The answer is I don't know.

Now a question for you -- are you looking for a solution or are you looking for an excuse to do something different? Reading your new essay it *seemed* the latter. If so, go for it. If the former I do have some ideas on how to transmit categories in newPost.

But I don't want to be in a position of holding back the tide. If you can convince other developers to do it differently, more power to you, just don't put me in the way. The two seem wholly unrelated.

My goals are not specific to this API.

It has been my experience that it is very hard to capture the need to design in extensibility when crafting a network protocol. Talking about such things abstractions rarely works. This API has provided a real world example that people can "grok".

If you do solve the multiple categories in a single newPost, I will update this essay with the results.

I've been emailing with Sjoerd Visscher offline about this, and I believe he will present the solution we have come up with.

Also, I'd request in the future, when you're using my work as a foil, that you say so -- so I don't have to drop my breakfast on a Sunday morning and quickly come and respond, esp when the message isn't really for me. If it's not urgent, say so, please.

Dave: please relax a bit.

I asked the same question nearly two weeks ago, pointing to the same core element, and asking about multiple elements with the same name in an XML RPC struct.

I labelled this blog entry "patient evangilism" with a pointer back even further than that... over eight months ago. That blog entry contains a pointer to a prior point in this discussion - way back in 2001.

I suspect that this discussion will continue into 2004 and beyond.

Sam: I'll stop reading your site. Take care.

I find that when I use xml-rpc, i use structs more and more.

I'm using xmlrpc for an astronomical control pipeline. Since I have control of both ends, I define a body struct(besides a header and data struct(for transporting c structs, the latter)) with arbitrary key value pairs, and an opcode and msgtype unsigned int at the top level.

This works surprisingly well, and lets the astronomers use python or perl in really simple ways, which is the main benefit of xml-rpc over REST. For them, the URL is essentially opaque, an all they care about is the opcode and body really, eg. opcode=TAOS_DOME, body: observatory=A, open=1.

On the other hand, for more explicitly web oriented apps, i find a clear need for more descriptive URL's, no matter what underlying protocol I use. REST's insistence on not using methods in the URL makes me have to carry method names in the transported xml, independent of the underlying protocol.

At the end of the day, extensibility depends on how well you write the underlying server. Extra params can be carried as structs in xmlrpc, or in the xml document in document-oriented SOAP or REST. The lesson for me has been to let this transport payload be loosely defined, no matter what my protocol..

Also, ofcourse, if one is not using http (xml-rpc over message queues in routing daemons, for eg), the URL without the http part still matters..

So its important to craft it carefully. Being thorough about it gets us closer to the RDF goal of describing every resource with a URI, which is a very laudable goal. People tout this as an advantage of a RESTian scheme, but I think thats its really very poor and opaque choice of endpoints by developers in xml-rpc and SOAP (unless there is end-to-end control, as in my astro application).

Senator Kennedy's new inaccessible web site. On writing for the web. The Python path module. The art of conversation. How to reset your Mac laptop's power management unit. Thoughts on improving Syndirella. More on XHTML 2.... [more]

Trackback from dive into mark

Looks like a little extra patience might be necessary.

:-)

Patient Evangelism. Todays new essay is a follow up to a blog entry posted over 8 months ago. The MetaWeblog API has since evolved with the introduction RSS 2.0, and this lead to a new RFC. My questions on that RFC have gone unanswered, and I have...

Sam,
Nice write up, though I'm obviously biased :)

Your example does raise one question. I noticed that the username and password in the SOAP example were inside the 'blogger' element. Aren't there any standardized authentication mechanisms for SOAP?

That's a big can of worms, be carefull before you take the lid off ! (ref. joe's auth question)

Joe/Simon: I'm in a rush (about to catch a plane), but some of the foundations can be found here:

http://www.w3.org/Signature/
http://www.w3.org/Encryption/2001/

Apache has an open source implementation:

http://xml.apache.org/security/index.html

More noteworthy thinking in the realm of TrackBack and simple RESTful interfaces. Scott Andrew says the TrackBack notification format should supplant the weblogs.com ping format. I agree. Also Mark Paschel's TBPY a stnadalone TrackBack CGI written in Phython.... [more]

Trackback from tima thinking outloud.

Sam,

What an amazingly cool essay - it really captures some of the issues we had addressed during the 1998-1999 evolution of SOAP. Here are a few friendly amendments:

1) Wrap the <item/> in body inside an element (call it <Submit>?) that conveys the intention so I don't need to rely on the transport goo (e.g., HTTP POST) to determine message semantics.

2) Allow multiple items per message - this way if I've done a lot of editing on a plane, when I sync up I'm not having to send N messages when 1 would do.

3) My personal preference would be to allow WS-Security to be used to get transport-independent signing/sealing. I can understand not wanting to mandate it given the dearth of xml dsig/enc implementations for ruby, but for Java and .NET, these can be had pretty easily and I'd like to be able to leverage what I have at my disposal. Maybe some flexibility here would be a good thing?

4) This should work over SMTP as well. Perhaps Ingo can get it up and running on his stuff. A jabber and BEEP implementation would be nice as well. I believe there are (informal but de facto standard) SOAP bindings for each of these transports.

DB

[via Simon Fell] Agreed. I still haven't found an answer to the question as to how one codes multiple categories in a metaweblog API. If you are going to pass structured data, I find the SOAP serializations are much simpler and easier to understand t... [more]

Trackback from Sam Ruby

Thank you. I've tried to be consistent.  Advocating a single, uniform, consise, and extensible data format as opposed to unique formats for each intended purporse.  Alternatives which generally are simultaneously more verbose and yet somehow manage to... [more]

Trackback from Sam Ruby

May 03, 2003 a review of blogging APIs As I was looking again at the space of remote-access APIs for weblog software (working on the XML-RPC Weblog Sync feature of clevercactus), I found that there was no side-by-side comparison of the main...