Forward Motion!
After years of no updates, the the limitation of XML-RPC strings to ASCII characters has been lifted. This apparently has been a source of significant frustration to XML-RPC users.
Rogers Cadenhead anounces the launch of yet another effort to clean up the RSS specification via a profile. He initially names his effort "Site Syndication Format".
And in a move that I haven't completely groked, Dave apparently welcomes everybody to name their formats RSS 2.0.
Why is all this happening? I have a theory: a little competition is a good thing.
To everyone who has contributed to echo/pie so far: your work is already having an impact. Keep up the good work!
Sam it's not so mysterious. I'm saying that if you'd like to write a spec that describes RSS 2.0, go for it. But please describe RSS 2.0, not some other format. It would be like writing a tour guide to Argentina. It should actually be about Argentina, not Brazil. I wouldn't have to explain this to most normal people. There's something about the warped mind of programmers that makes it necessary to say what's totally obvious? Maybe it's the legal atmosphere around these parts? Not sure. Have a great day.
Posted by Dave Winer at
Dare Obasanjo
Sam,
Before I invest any more effort in Echo/Pie I'd like something clarified. Given this "forward motion" and potentially more acts of openness from Dave, will IBM be deeming the Echo project as unnecessary?
If so I believe a heads up is in order.
Message from Dare Obasanjo atDare, simply put: I see this as validation that this work is vital and important and will have a lasting impact. If anything, I plan to pick up my pace.
Tomorrow I am going to start to look into adding support in the validator. Or perhaps to begin prototyping the API.
Posted by Sam Ruby atDave, I see you linked to this in the FAQ, and wondered if it was a joke.
It was not a joke. I don't fully grok what you are proposing. I just went back and checked, and Rogers clearly stated that he was developing a protocol from scratch, and the scope was not limited merely to clarifications, but also could involve the correcting of a number of issues with the RSS 2.0 spec.
How about we take a look at a specific issue? There is confusion over the proper use of link tags. The original specs say one thing. The predominant usage in current tools is to do another. My preferred fix would be to pave over the cow paths.
Would it be OK to publish a spec, call it RSS 2.0, and specify that link tags are exclusively to be used to specify permalinks? Or should a spec that includes this definition be called another name?
Posted by Sam Ruby atSam, I don't know how to answer that question. It depends on what your goals are. Like Dare, I'm confused. Maybe the next thing for you to do should be to explain what you're doing, since there seems to be a difference betw that and what the project formerly known as Echo is doing. Is there?
Posted by Dave Winer at
Dave: my goals are simple. Increase interoperability. Reduce confusion.
I gave a very simple and very specific example: the link tag. Let's agree to one definition. Preferably the one that pretty much everyone is using today.
Until we can get an answer on whether or not such a clarification is permissable in an RSS spec, I believe that we have a very clear answer to Dare's question as to whether our work here is done: no.
Posted by Sam Ruby atI just went back and checked, and Rogers clearly stated that he was developing a protocol from scratch, and the scope was not limited merely to clarifications, but also could involve the correcting of a number of issues with the RSS 2.0 spec.
Correction: SSF-DEV is creating a specification from scratch to describe the protocol that already exists.
The link/guid issue is the first one being discussed.
Posted by Rogers Cadenhead atSam, when I think about these things I tend to think in terms of the best developer docs I ever used, which were the Inside Macintosh series produced by Apple in the mid-late 80s. It's a long story and it's late, but they had a concept of Tech Notes, and sometimes a note would be quite elaborate, with illustrations, sample code, anecdotes. They were fun to read. A bunch of them would arrive every month, and that always meant I stopped everything I did and leafed through them, and often found answers to questions that had been on my radar, and they were always good reads.
My point is this -- if something needs clarification -- then clarify and don't worry about where it fits in. We need more docs, for sure. We tend to stand on each others toes, but there's lots of room. Write a tech note, ask for feedback, and then iterate until it's done. I find I can do one tech note a day. If we get a few out there, we've improved the lot of the RSS developer a lot.
Anyway, those are my thoughts for the evening. See y'all tomorrow.
Posted by Dave Winer atRogers, then can we be safe in assuming that you're not making any adjustments to the implementation of RSS 2.0 that folks like Ben Trott have asked for? You're creating basically a model of the existing RSS 2.0, without any enhancements. Correct?
If so then I think a clarification needs to be made here. Echo is not a specification, nor is it's primary purpose to provide a syndication feed.
Echo is first and foremost, an open source effort to model the business data of a 'weblog'. By doing so the hope is to create formats and specifications that can be interoperable because they have a good, solid understanding in what the data is -- literally, building from the ground up, with no prior assumption, and not based on a prior implementation except as it helps to clarify the data.
This is not just about creating a syndication feed format, or an API. These are just the beginning of the technologies based on the effort, but by no means the last implementations we'll see.
At least, this is my understanding.
Posted by Shelley atDare Obasanjo
Sam,
Your answers do not reassure me. You talk about this effort as if it is primarily a way to gain leverage over Dave and have him fix to parts of the RSS spec that people felt were vague. To me this is not a worthwhile goal compared to all the effort people have expended. This could have been achieved by any one of the various attempts to profile RSS or even in a spec that described RSS best practices. Heck, you author the RSS validator which gives you a lot of influence in that direction.
Even then, my personal opinion is that RSS is a good enough technology. All the interesting things happen in namespaced modules anyway. I've only been interested in fixing the problem with the current crop of weblogging APIs (some of which I described at http://www.kuro5hin.org/story/2003/6/29/22931/0682) and working on the syndication related stuff was a stepping stone in getting to that direction. However, I have seen very little discussion of this by yourself or many others in the Echo effort and instead a focus on comparisons to RSS as if there is anything significantly wrong with RSS or that anything major will be fixed at the core.
If the only thing needed is clarifying RSS 2.0, I'm sure any one of us could knock out an annotated RSS 2.0 spec in an evening then request feedback from the community. So I repeat my original question
Before I invest any more effort in Echo/Pie I'd like something clarified. Given this 'forward motion' and potentially more acts of openness from Dave, will IBM be deeming the Echo project as unnecessary?
It seems you've already hinted at the answer but I would prefer a straight Yes or No instead of inferring one from your response.
Message from Dare Obasanjo atDare, which part of "I plan to pick up my pace. Tomorrow I am going to start to look into adding support in the validator. Or perhaps to begin prototyping the API." was unclear?
Which part of http://www.intertwingly.net/wiki/pie/EditingApi and http://www.intertwingly.net/wiki/pie/EditingApiConceptualModel don't you like, and why aren't you working on improving it?
Posted by Mark atDare Obasanjo
Mark,
Considering I wrote most of the current content on both of the pages you linked I don't think there's any question about whether I am "working on improving it". However, since Sam who is managing this project is doing so in an official role (and I'm doing this in my free time) and he's mentioned many times about the significance of cleaning up some issues with RSS I'd like to know whether I'm wasting my free time or not.
That said, there is nothing in the current discussion on both the pages you have linked to that precludes RSS 2.0 being used as the payload of the messages being sent. I did this on purpose because I suspect that if Dave keeps being as cooperative as he's been in the past day or two then many of the issues people have with RSS 2.0 would have vanished. But now I'm not even sure what the priority of the API is given that everytime I see Sam or anyone else who's been endorsing the project talk about Pie/Echo it's RSS this and RSS that.
Message from Dare Obasanjo atIf Dave wants to go do his thing with his specs, that's fine. Great. The community felt there was a need for errata, and now we have errata. A clear win for everyone who uses those technologies.
But I don't see how that affects this project. We're doing exactly what Dave told us to do: creating the SOAP of syndication (and the SOAP of editing APIs as well). Making a next-generation format, with a new name. To quote Dave:
"""
1. Think of RSS as you think of XML-RPC. A non-buzzword compliant application of XML.
2. Assemble a small group to create the SOAP of Syndication, designed to be totally in synch with the best practices of the W3C. I won't be part of that group, but I will support it. It must not use the name RSS for its format.
3. Go on from there.
RSS is what it is. The problem, since 2000, is that people are trying to change what it means. But it's already out there. Just as SOAP couldn't have changed what XML-RPC is, the compliant syndication format can't and shouldn't erase RSS.
"""
Dare, you say "RSS is good enough", but then you say "all the interesting stuff in RSS happens in namespaces". So what you're really saying is that you're trying to change what RSS is. You're trying to make it complicated, to shoehorn stuff into it that wasn't there to begin with, and that doesn't really belong there now. (Not just you. I've been a major player in this effort before too. We're all guilty of trying to remake RSS in our own image.) Well, don't do that. Just stop. Leave RSS alone; it's had a hard enough life already.
The-project-formerly-known-as-Echo will not erase RSS or even "compete" with RSS, just as SOAP does not "compete" with XML-RPC. They co-exist, they serve different needs. If RSS (as-is) works for you, use it. It works for the BBC; heck, they use RSS 0.91 feeds! Good for them. But I want to do all sorts of fancy stuff in my feed that RSS doesn't allow for. Sure, I could shoehorn a bunch of stuff into namespaces and call it RSS, and it would be, technically; I've been doing that for months now. But I need a format that is geared for power users like me.
SUPPORT ECHO! LEAVE RSS ALONE!
Posted by Mark atLeave RSS alone
We've all been guilty of trying to remake RSS in our own image.... [more]Trackback from dive into mark at
Dare Obasanjo
Mark,
We obviously have different opinions about syndication. From the discussion so far, anything I can do with an Echo/Pie/whatever syndication format I'll be able to do in RSS 2.0. I don't see much difference between the core Sam described at http://www.intertwingly.net/blog/1499.html and RSS 2.0 except that now for some of the things I'd like to do with "virtual RSS feeds" such as provide a view of my Windows EventLog or an NTFS file share that I can display in my news aggregator I have to generate irrelevant or redundant information such as having both link and id or coming up with an author.
The only thing that is of interest to me is a unified posting API. However if this is going to work somebody is going to have to make it a spec (no one in his right mind is going to code against the descriptions in a Wiki) in which case I'd like to know if the person currently managing this project considers this a high priority or is simply making there exists a well-defined syndication format the main priority.
This question is for Sam not anyone else. If I didn't feel that this is something that others would also find interesting I'd have just sent him an email.
Message from Dare Obasanjo atQuick question for the true lawyers in this forum: does the US legal system use anything like "rationales" and "prior art", or are the words of the "law" an absolute truth, and the only truth there can be?
Here in Sweden, a law must always be interpreted by a court, and they are supposed to use both material from when the law was first written ("discussions, rationales, examples"), and from higher courts ("prior art, existing implementations"), as well as works of legal scholars ("best practices") when doing so. No law exists in a vacuum.
(I'm intentionally not trying to translate the swedish legal words, to avoid confusing the real lawyers).
I'm beginning to think that this is why it's so obvious to me that you cannot read a specification and ignore everything that led up to it, and everything that has been built on top of it.
While in contrast, all the americans attacking Dave for his shitty work seem to think that specifications always have to be 100% perfect, and don't seem to understand that no specification exists in a vacuum.
"The only thing that is of interest to me is a unified posting API. However if this is going to work somebody is going to have to make it a spec."
Just go ahead and write one, Dare. I promise to use what you come up with, wherever I can (especially if it's based on POST with RSS payloads)
The only way to make something happen is to do something. Don Park explained "funkiness" ages ago, Rogers is writing a new document clarifying an existing format, and codifying best practices, I've done the same thing for XML-RPC with help from others. Flaming someone on Sam's blog, or ranting about how good the new format will be once everyone's been forced to use it, won't move the world anywhere.
Fredrik,
I don't agree that the law example you gave is a good practice that should be translated into specifications.
It's true that, over the course of time, experience with a law (or file format) will uncover some corner cases that aren't addressed by the current legislation/specification.
Coders/lawyers should not have to go hunting around what is "accepted behaviour" and history books to determine the correct protocol usage or law. That experience should be codified with revisions to the specification/law.
The specification should be the final word on the format. No FAQs, no non-specific ranting about "funkiness", no flamewars, no "common usage". I should be able to read the spec and produce a conforming implementation that works in the real world. If this is not the case, and I have to keep going back and tweaking things, it's time-consuming, expensive, and a pain in the neck for me.
Posted by Jim atShelley is right. Until we have a shared understand of basics like what <link> tag means, it difficult to have interoperable implementations.
Frederick is right. There always will be edge cases. But, at this point in 2003, basics like link tag shouldn't be one of them.
Dare, a cleanly and thoroughly specified weblog editing protocol is stated goal of pie/echo/tbd.
Rogers, I'm rooting for you. I'll be watching and contributing where it makes sense. FWIW, I agree with loluyede - making things not optional is key to progress. This will involve difficult decisions. Do you declare the predominant use of the link tag wrong? Should link tags be made required, like they were in 0.91? As I said, difficult decisions.
Posted by Sam Ruby atDare Obasanjo
Sam,
It seems I wasn't clear. I don't care about "Echo: The syndication format" because RSS is good enough for me. All I'm interested in is an editing API and quite frankly it could just as easily use RSS 2.0 payloads as it could "Echo: The syndication format" payloads.
If the chances of "Echo: The syndication format" are unlikely to come to fruition because this is all just a ploy to get Dave to tighten up the RSS 2.0 spec then I'd rather be told this up front and just start working on an editing API that is RESTful/SOAP-y/XML-RPC-delicious and uses RSS 2.0 as a payload.
Whether RSS 2.0 is cleanly and thoroughly specified when it comes to being part of the syndication format isn't really relevant when it comes to the editing API because it isn't exactly isomorphic. For example, witness the confusion with <title/> elements and Joe Gregorio's first pass at the CommentAPI. ,
Recap: I'm doing this in my free time and I'd rather not spend time working on stuff that isn't going anywhere. Secondly, I don't think RSS needs replacing (a tighter spec, Yes, replacing, No) although I do believe the current crop of blog posting APIs need to be replaced and unified. Finally, working on the blog posting API would go much more rapidly if it was known up front that it would be using RSS 2.0 payloads (like the MetaWeblog API) as opposed to some yet to be determined syndication format as payloads. Heck, I could hack in support for a client by this weekend if all I had to do was create a version that utilizes RSS 2.0 payloads. The main problem would be hacking support into a test server but I'm sure I could find some ASP.NET book and a build of BlogX to play around with.
Message from Dare Obasanjo atSam we have interoperable implementations right now.
Mark I didn't tell you what to do, and an Apple Tech Note from the 80s is the furthest thing from an errata. It's more like one of your best Dive Into Mark tutorials.
About Ben's wish list, when I read it, I felt that everything he wished for had already been done in RSS 2.0. But that's just me.
And to Jim (what's your last name) in fact, in the real world, prior art is part of every successful designer's toolkit. I'd like to know where you learned the principles you espouse. Did you invent them? Have you put them to the test by developing actual software with them.
Posted by Dave Winer atDare, I wonder if you have a wishlist for editing APIs? If so, I'd love to see it.
Posted by Dave Winer at
Dave,
My list of issues with the current crop of blog editing APIs (specifically the MetaWeblog API) are documented at http://www.kuro5hin.org/story/2003/6/29/22931/0682
Posted by Dare Obasanjo at
Mark, I just read your post on Dive Into Mark, and for the first time in quite a while -- Bravo!
Perfect. Now you'll go look to see if there really is a SOAP of syndication formats, now that you don't have to worry about anything other than that. I've found in my experience that sometimes these are wild goose chases (like my experiments with CDF and MCF that everyone likes to talk about). Even Fat Pages which worked well for Frontier never caught on outside our community. Now you have the deck cleared of irrelevancies, now you can focus on the problem at hand.
Excellent.
Posted by Dave Winer atDare, you were clear. And my response was simple. And it is prominantly displayed on the RoadMap. In short, I want a cleanly and thoroughly specified set of ['syndication format', 'archiving format', and 'weblog editing protocol'] using a common syntax.
If this is possible with RSS 2.0, then great. I'm in. If not, I still want a cleanly and thoroughly specified set of formats and protocols. Given a choice between the two, a cleanly and thoroughly specified RSS 2.0 syntax is simultaneously the most preferred and apparently least likely to succeed - based on observations on how questions on the meanings of basics like the link tag seem to go unanswered.
I can't tell you what the future holds. I can't tell you what will succeed. I won't preclude either the most preferred or the most likely to succeed alternatives at this point.
I will tell you what I am working on at any point in time. And I will cheer any and all progress made toward the goal stated above.
Posted by Sam Ruby atSam,
Thanks for the clarification. In this case it seems to be a more prudent use of my time to start with the base at http://www.25hoursaday.com/PieEditingApiConceptualModel.html and work it into an blogging API proposal that uses RSS 2.0 payloads. In this case I'll spec RESTian, SOAP and XML-RPC bindings with the RESTian approach being the preferred/required implementation and the others being there for programmers who want to take advantage of toolkits that make those approaches easier than futzing with XML and HTTP directly.
To respect prior art I'll try and make XML-RPC bindings backwards compatible with the MetaWeblog API although if this hampers the design I'll rethink that goal.
Thanks.
Posted by Dare Obasanjo atBTW, I have a different theory about why you're seeing motion now.
Back when I was writing the RSS 2.0 spec, I asked for ideas, and only a few people participated. A very few people.
Now, for whatever reason (mostly some ridiculous ad hominem attacks) people started coughing up their ideas. It's not something you could prove in court, but all of a sudden people started looking at the RSS spec and commenting on it.
I noted a few weeks ago that one of the experts in RSS didn't even know how the isPermaLink attribute on the guid element worked.
So my theory is that competition isn't the reason you see movement, it's that people are actually looking at the specs now. The timing is a bit unfortunate, but we can probably work something out.
Posted by Dave Winer atSam, try asking the questions in an environment free of ad hominems. As usual you seem to be blaming me. I have a life outside your needs Sam, and the ad hominems add a tremendous amount of overhead, so less of my time can be spent on substantive things. You have contributed to this misery, even though you deny it. Also, even more basic, don't assume I understand your questions, and sometimes you interpret things in such wild ways. I was able to figure out without asking that Rogers was simply interpreting RSS 2.0. He stated it very clearly. Why did it show up on your site as a reformulation of RSS 2.0. Same with Aaron
Posted by Dave Winer at
I believe that Dave Winer is referring to Phil Ringnalda. I will agree that whether or not Phil's coming to this bit of enlightenment was due to competition, or a ridiculous ad hominem attack for that matter, is not clear.
Perhaps we are both wrong and all this is merely serendipity. If so, I am going to do my part to manufacter more of it.
Dave, please point to any ad-hominems in my comments. I will strike them, even if they are my own
Posted by Sam Ruby atForward Motion!. XML-RPC spec updated. "Site Syndication Format" launched. Lots of RSS 2.0 specs? Why is all this happening? I have a theory ... [Sam Ruby]...
Excerpt from Keeping track at
Shelley: That's correct, as far as I'm concerned. SSF-DEV is an effort to find the things that an RSS 2.0 implementor has to make an educated guess about because the spec is imprecise, contradictory, or unclear.
I don't know that the link/guid issue is one that lends itself to a strong resolution, but I'll defer that discussion to the list.
Posted by Rogers Cadenhead atOh, I'm sure Dave's referring to "Mr. Encyclopedia." And his response to the way that "is optional, its default value is true" doesn't stick in my head the way that something like "a <guid> is a permalink unless it has the attribute isPermaLink="false"" would is one of the reasons I'm spending my time working on things where people are kind and helpful, and assume good intentions, instead of acting like a bunch of rabid wolverines. What I want out of syndication, whatever name it has and whoever's server the spec lives on, is a situation where that would be treated as a bug report, not as evidence of someone's laziness and stupidity.
Posted by Phil Ringnalda at
"that would be treated as a bug report, not as evidence of someone's laziness and stupidity."
If I were a lawyer, I would object -- "Assuming facts not in evidence."
In fact, I think you're neither lazy or stupid, I think you're hard-working and super smart. I was commenting on the culture, and how little respect there was for the spec in the culture. It was the opposite, I was using it as evidence of your thinking I was stupid or irrelevant. I went to all the trouble to write up a spec, with very little help or review, and no one even bothers to read the damned thing.
See everyone's feelings are hurt. And it never seems to end. Why not hit the reset button, I endure so much of other peoples' pain, could you set aside a little of your own and move on.
What do you say?
Posted by Dave Winer atAnd by the way Phil I very deliberately did not use your name so it would not be seen as personal. Once again, Sam steps in to fan the flames. I'm really getting a bad feeling about this.
Posted by Dave Winer at
An effort to clean RSS2
After the announcement by Dave Winer of some clarification on the XML-RPC side, a new effort for cleaning the RSS 2 specification :Rogers Cadenhead anounces the launch of yet another effort to clean up the RSS specification via a... [more]Trackback from Misc... at
When you talk about an specific well-known event (at least, to those of us who read Phil's weblog) using the same language you used during the fracas, then even without a name, the comment is personal.
Posted by Mark "Hex" Hershberger at
Mark, I give up. Really -- I can't participate in this anymore. You guys miss something very important, I'm just one person, and I just don't have the time for all the overhead here. Good luck with your project, I just can't contribute any more time.
Posted by Dave Winer at
Dave,
My intention is not to scare you away. I value what you've done and what you have to say.
I do think this whole discussion is too much about personality, though.
Posted by Mark "Hex" Hershberger at"See everyone's feelings are hurt. And it never seems to end. Why not hit the reset button, I endure so much of other peoples' pain, could you set aside a little of your own and move on."
Dave just reminded us (and not for the first time) exactly why The Project Formerly Known As Echo is taking place.
Sadly, the need for such a statement makes it brutally clear who actually is vs. is not prepared to move on. Which, unsurprisingly enough, is yet another reason why TPFKAE is taking place. :(
I wish I didn't have to sound so negative, but the amount of stop energy being applied to TPFKAE in the most recent hours/days is disappointing. That much of this stop energy is coming from the very person who popularized the term is unsurprising yet still saddening.
Posted by Jeremy Gray atI think (I'm never sure when it comes to social matters) that Sam was right to make it explicit what Dave was talking about: we all seem to have these coded conversations about our numerous festering wounds, where only those in the know can even guess at what's going on (lacking the context, the whole Tim Bray/Charles Goldfarb thing is just going over my head). Who knows, maybe someone would crack my coded reply, and realize that in fact I've read the spec until my eyes bleed, and the way <guid> is described just doesn't work to make <guid> == <guid isPermaLink="true"> stick with me.
I'm sure I agree with Dave: I just don't have the time and energy for this any more: once there are people doing nothing else all day long but changing stuff around in the wiki, chasing around commenting on a dozen weblogs, coming back and declaring consensus thirty minutes later, there's just no way I can keep up, much less contribute.
Posted by Phil Ringnalda atSadly, the need for such a statement makes it brutally clear who actually is vs. is not prepared to move on. Which, unsurprisingly enough, is yet another reason why TPFKAE is taking place.
I wish people would resist the urge to define the "Echo" project as a reaction to a specific person.
The idea is interesting, the collaborators are talented, and the name will be distinct from existing syndication formats.
It isn't in anyone's best interest for Echo to be backwards-compatible with the fights we've been having for years around the subject of RSS.
Posted by Rogers Cadenhead atRogers: well said.
My focus has returned to technical matters. There is so much to be done. Defining the API. Implementing the validator. Prototyping with real code using my weblog. That's what I plan to be working on.
Posted by Sam Ruby atIntellectual Blindness
How we interpret what we read is subject to our biases. At the extreme, total blindness occurs, fabricating something entirely different. I am no exception and had many embarrasing moments when such blindness strikes. Yesterday, it...Excerpt from Don Park's Blog at
Excerpt from Doc Searls Weblog at
Well, this thread degenerate quicker than usual... but there is one remark I have to comment on :
"Back when I was writing the RSS 2.0 spec, I asked for ideas, and only a few people participated."
I know for a fact there was a lot of input from people that at that point in time tended to favour the RSS 1.0 standard, but saw RSS 2.0 as a way of healing the rift. Shelley contributed some excellent compromise suggestions, as did Sean B. Palmer. Effectively an RSS 1.0-compatible simple format was possible. Win-win. Also many people said you were moving too fast, and questioned the need for a jump from 0.93 to 2.0. But all this was ignored.
Posted by Danny atDare:
In this case I'll spec RESTian, SOAP and XML-RPC bindings with the RESTian approach being the preferred/required implementation
Ugh... a REST requirement seems incredibly unnecessary. A preference, fine, but a requirement? Nope, no thanks.
Posted by Roger Benningfield atRoger B, I don't understand. When you HTTP GET an RSS feed, that's REST. In nee Echo, you'll be able to GET feeds, entries, and other weblog things, and PUT them, and DELETE them, and use GET to do queries to get lists, searches, and POST to create new items with new IDs/URIs and whatnot. That's basic HTTP, and that's all REST is. Do you have some other understanding of REST that makes it seem more complicated than that? Do you have links to messages or articles that discuss that?
It also appears the suggestions some are using for SOAP are the same REST principles, except that instead of GET returning an Echo document, it returns an Echo document wrapped in a SOAP wrapper.
Posted by Ken MacLeod atExcerpt from Doc Searls Weblog at
Excerpt from Doc Searls Weblog at
The Not RSS thing
There's a new API spec being proposed, so you'd think I'd be getting involved. But I don't really have the energy.... [more]Trackback from Kalsey Consulting Group :: Measure Twice at
Necho
Encore beaucoup de remous autour de «Necho» provoqués par l'errata de Dave Winer {what funky means in a simple non technical language>} sur la spécification XML-RPC....Excerpt from .Conforme at
To Ken:
About why using a GET approach with RSS, but an XML-RPC approach for the API, check my weblog.
Comments are welcome.
Posted by JY atThe Project that isn't called Echo
Have you heard of the Echo Project? No? Well, it isn't called Echo anymore, because something else already had that name. Rather than come up with a new name, people are currently calling it The Project Formerly Known as Echo, or (not)Echo, or Echo...Excerpt from nonymous.org at
Intellectual Blindness. How we interpret what we read is subject to our biases. At the extreme, total blindness occurs, fabricating something entirely different. I am no exception and had many embarrasing moments when such blindness...
Excerpt from André Venter: Dev at
An effort
After the announcement by Dave Winer of some clarification on the XML-RPC side, a new effort for cleaning the RSS 2 specification :Rogers Cadenhead anounces the launch of yet another effort to clean up the RSS specification via a... [more]Trackback from Misc... at
Oh me oh my!
Hot tempered are we?
You know, it will all develop over time.
So? Well, joining forces was 'always' the way of the web.
That's the benefit of Internet for the developer crowd.
For personal matters there's still email.
You know!
:-)
Posted by Bertil Gralvik atSam Ruby: Forward Motion! (Dare Obasanjo)
[link]...Excerpt from del.icio.us/heinzwittenbrink/Atom at
Competition is indeed a healthy thing. Without it we'd all be using NCSA Mosiac to read each other's weblogs. ;-)
Posted by Mark at