James M Snell wrote:
Robert Sayre wrote: > Yes or No: Is asking what capabilities existing XML-RPC protocols > provide is a productive way to set the limits of the Atom Protocol?
Of course not. I for one don't really give a rip what the existing XML-RPC API's currently provide or don't provide.
I certainly care about what they provide, but my proposal was based on problems I had with the deployed draft-gregorio-09 protocol.
Sam once told me a story about a group of important open source developers having an argument where all sides contended their suggestion was "the simplest thing that could possibly work." I see a similar problem emerging around the catchphrase "YAGNI" with regard to the protocol.
Here are some observations I've made:
All of the existing XML-RPC APIs provide some sort of querying, yet it's been said that avoiding querying would be good. YAGNI? [0]
Client developers have users wondering why blogging clients are so completely crippled compared to FTP and Email clients. Rename an image? Have a folder full of drafts? etc. YAGNI? [1, 2]
There's been continuous feedback that feed files with link relations just aren't good enough. I tend to agree, since we've been unable to say anything meaningful about managing feed state. YAGNI? [3]
It's been said that the API should be able to use static files, but none of the current protocols allow this. In fact, I don't know of any widely-used authoring protocol that does. YAGNI? [4]
Two of our biggest server implementors have asked for super-basic date range queries. YAGNI? [5,6]
I was asked to write an entire draft illustrating my thoughts. It's certainly not perfect or done, but it's much more capable than any other proposals we've had. The only objection I heard was something about web architecture, but no actual use case problems. And, truth be told, I could live with "URI freedom", since it will cause all sorts of problems by crossing hierarchical and security boundaries, and then converge on my original suggestion. YAGNI? [7,8]
We've given URIs to all sorts of things that don't have URIs in other protocols. YAGNI?
There's no efficent way to incrementally update a collection with the current protocol. You see, after any protocol action, the collection representation expires, and you have to re-download the whole feed. This makes things pretty much intolerable on a cell phone. YAGNI?
So, when I suggest something, I usually try to ensure that it's "the simplest thing that could possibly work" and Yes We Do Need It. Obviously, I could be wrong, so I'm looking for reasons why I am, or why it's not a good tradeoff. I'm not particularly interested in catchphrases or religious objections. We could do the whole thing in SOAP through one endpoint, and I would be fine with that, if it worked. If, the WG decides on a bunch of stuff I think is horrible, I will still do my best with the draft.
Robert Sayre
[0] http://www.imc.org/atom-protocol/mail-archive/msg00300.html [1] http://blog.kung-foo.tv/archives/001228.php [2] http://inessential.com/?comments=1&postid=2988 [3] http://bitworking.org/news/Proposed_changes_to_draft_gregorio_07#X3 [4] http://www.imc.org/atom-protocol/mail-archive/msg00290.html [5] http://www.imc.org/atom-protocol/mail-archive/msg00184.html [6] http://www.imc.org/atom-protocol/mail-archive/msg00200.html [7] http://www.imc.org/atom-protocol/mail-archive/msg00384.html [8] http://www.imc.org/atom-protocol/mail-archive/msg00408.html
