In progress. Discuss.
In progress. Discuss.
Brad Wilson: I wonder when my program is going to get TiVo-style smarts and say "If you like Don, Sam, Joshua, and Ingo, then you'll love Sam Gentile and Craig Andera!".
Note that Tivo doesn't say if you love CNN, MSNBC, and the History Channel, you'll love the Discovery Channel. The recommendations are at the individual show level. Now that's what I'd like to see.
A spambayes in reverse. Read a few blog entries and push on little green thumbs up or red thumbs down icons. Then any all all posts on topics that interest you in your greater neighboorhood will come to your aggregator.
In processing a comment API request, I may end up grabbing excerpts, formatting, etc. I can also spell check. Would there be interest in a variant of the comment API which simply returns back what would have been posted instead of actually doing it?
It seems to me that there are the following options for implementing this API:
One thing I think is important is that such an option not be ignored. In other words, I presume that a client would prefer a failure (HTTP status and/or SOAP fault) than to have the request actually processed. Unless somebody sees something I don't, that reduces the options to two: SOAP headers with mustUnderstand attributes have this semantic, and clearly routing to a different URL can be presumed to do this effectively.
Dare Obasanjo: I'll definitely add support to Joe's CommentAPI to RSS Bandit but I doubt I'll be doing the same for Sam's alternative SOAP version since I can't see any motivation for supporting both besides buzzword compliance.
At the cost of optionally supporting an SOAP envelope and responding in kind, I get better and easier integration with tools and languages like Radio and C#. If two elements and future extensibility is too heavyweight for you, then no problem. That's what optional means.
As to your uncertainty about which version of XHTML is meant by <xhtml:body>, wouldn't the same concern (and more) apply to <content:encoded>?
Chris Anderson: if you favorite aggregator isn't showing the full text of my blog, send them a mail and get them to support <xhtml:body>!
My weblog now validates as XHTML strict, and my implementation of the Comment API will now produce and consume XHTML bodies.
Users of back-level browsers may find that the comment form doesn't remember you any more. If this function is important to you, you will need to find a browser that passes this test.
My WSDLs for the comment API (example) simply declare xhtml bodies as mixed sequences of any for now. Let me know if it would help if this were restricted in some manner.
Don uncaves. ;-)
Accordingly, I've converted my rss 2.0 feed from <content:encoded> to the to the more bandwidth and xpath friendly <xhtml:body>. It looks like gotdotnet and blogx users will soon follow. Hopefully the owners of the wellformedweb and w3future weblogs will take notice.
The updated feed is valid, and it uses namespaces in exactly the way that rss 2.0 and xhtml intend. I've tested it with radio and syndirella.
Don Box's RSS 2.0 feed now supports <content:encoded>. I was kinda hoping that it would support <xhtml:body> instead (literally instead of encoded). I'm sure that NewsGator would have adapted. Needless to say, I would have too.
ECMA: ECMA International (ECMA) is completing extensions to the widely used ECMAScript standard, currently being updated to its 4th Edition. The enhancements known as E4X (ECMAScript for XML) standardize the syntax and semantics of a general-purpose, cross-platform, vendor-neutral set of programming language extensions adding native XML support in ECMAScript.
John Schneider documented some of the earlier work that influenced this spec. I haven't kept close tabs on how it has evolved since then, but I'm confident that Tim Bray would approve.
Gordon Weakliem: While I accept that a large part of the problem with XML may be the popular APIs for dealing with it, I'm not sure Tim's answers are on target. Tim does draw the parallel to socket libraries in talking about interop. Sockets are still a pain in the neck to code at the socket level, I just hardly ever have to do it anymore. Maybe I'll feel the same about XML when I can substitute "XML" for "socket".
What's good about sockets isn't that you have to program at that level, it's that you can. The same thing should be true about xml. The problem comes in when people fool themselves into believing that xml should only be produced by programs for consumption by other programs.
Seairth Jacobs: Just when I thought that content negotiation was finally going to make it, I discover...
This weblog now supports the comment API, with a few additions.
Upon success, not only will a HTTP 200 status code be returned, but the body will contain an updated RSS item with the link, sanitized description, etc. Should there be any failures, I will report back with a HTTP 500 status code and a SOAP fault.
If the request comes in with a SOAP envelope and/or rdf:RDF element, I will respond in kind. That's just the kinda guy I am. Note that neither of these are required in order to do basic functions, and if not present, the response will be a clean simple item with no wrappers or namespace declaration.
However, be forewarned that in the future there may be additional functionality which may require SOAP and/or RDF. The commitment is that basic functionality will not require such wrappers.
Rael Dornfest: The O'Reilly Emerging Technology Conference has TrackBacks (and their associated auto-discovery RDF) baked into every single keynote, tutorial, session, and BoF page. This means you can target your bloggings of the event, providing both us, the organizers, and your peers with live feedback on the goings on. <good on you, terrie!>
Top 100 Technorati now sports the familiar white on orange icons for a number of feeds. Doing a quick scan the pattern seems to be that only those weblogs that have autodiscovery tags are so listed.
Before reading this, please read this.
Gary Burd: I checked in the basic code at Source Forge.
Cool. Please add rubys to the project.
Due to persistant prodding by Dare, I've created an addendum dictionary. Leave comments here if there are particularly troublesome words that you would like included.
I'm working on a membership registration service for intertwingly. At the moment, it simply replies that all ids are unavailable, but it will shortly send out confirmation emails and process responses.
Details on what I intend this service to be for can be found on the registration page. Feedback welcome.
Joe Gregorio: Attacking or trying to tear down other peoples work is non-productive and plainly not my style.
All I can say is that statements like this are not the way to get my cooperation.
While a number of intelligent people have contributed to the thread mentioned above, I still believe that creative solutions exist to all the "problems" outlined there.
Ones that are script/template friendly. Which are regexp compatible. Which are REST and SOAP compatible. Compatible with all the aggregators that I know of. And, in an area that I had not previously considered exploring, RDF compatible.
Tomorrow I plan to name that tune. After I locate my asbestos underwear.
An essay I wrote over seven months ago got 300 hits in the past 24 hours. This was due to a mention at the bottom of a lengthy and compelling rant by Joe Gregorio. Which was mentioned third out of a list of three items in a blog entry by Tim Bray. Which was mentioned by Slashdot.
While this doesn't guarantee that anybody actually read my essay yesterday, it does provide an indication that a large number of people actually read every word of Joe's and Tim's.
James Snell: If InfoPath does for XML and Web services what Excel did for Spreadsheets, bravo to Microsoft, good job.
James Snell: I'd like to propose a minor update to RSS 2.0. The update would add nothing more than a namespace declaration for RSS.
Daniel Berlinger: Sam's certainly consistent. Why the envelope Sam? No need to reiterate what it's used for in SOAP, but what's the benefit in this context? Why not just post the RSS and namespace the extensions? (as you suggest...) Does it improve interop when turning one standard into another? (just asking, no agenda)
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 contain less information. Alternatives which are considerably less extensible, if they are extensible at all.
Now in addition to the various uses I had collected before, I can add BlogPing. I say collected, as I didn't invent most of these. I have simply been collecting them in a manufactured serendipity sort of way.
Now to answer your question: the reason for headers is for orthogonal extensibility. What does that mean? Look at RESTLog. Whatever I place inside the item is saved permanenty. Suppose I simply want to pass an option to the RESTLog application itself? Similar question for validation, for archiving, for pinging, etc.
No, I won't give you a specific example today. I am merely recording observations, and encouraging people to leave room for potential future needs. When they arise, I plan to still be here. I am a very patient evangelist.
Gary Burd: I have been looking at how to merge my code with Sam Ruby's Mombo.
I'll comment when I see code. Don't worry about it being rough or incomplete. Publish early and often. Enjoy your trip.
Timothy Appnel: There are zero occurrences of the word asynchronous in the current JSR 172 (J2ME Web services) draft specification.
Joe Gregorio: I don't think I'll do it, but I am always open to persuasive arguments...
There's nothing more persuasive than seeing the problem with your own eyes. Since you seem to like C# on the client...
wsdl CommentAPI.wsdl csc capiClient.cs CommentAPI.cs
Adjust the wsdl as you see fit, try it in VisualStudio if you have got it, or simply declare this as a market you don't choose to serve.
P.S. by picking the same named element on the input and output messages, just be aware that you have fallen into an idiom.
I may not be reading this correctly, but it appears to me that Dave instead of federating we each run more servers that don't talk to one another. I must be missing something.
In any case, it looks like Dave and Lawrence are going to move the backend app that services weblogs.com to a faster server... something that many of us will greatly appreciate. Thanks!
Simon Carstensen: BlogPing is a Web application that tracks changes to weblogs and other news-driven websites through an XML-RPC interface and forwards the ping to a number of web services. A non-propietary weblog-ping service
Cool. This is an RFC, and I do have comments. None of which will be any surprise to regular readers here.
If you look at the original simple weblog ping interface, there are two parameters. blo.gs adds two more. Your proposed interface now has 7 parameters.
My suggestion to all: if you are going to design an interface to be used by others, start by making it exensible. Start with namespaces and named parameter associations.
Now, take a close look at the first 6 out of 7 parameters in the RFC. These are straight out of the RSS spec. Why not simply POST the RSS, possibly with an envelope?
Suppose you have a parameter that you want to pass that RSS doesn't currently support? That's what namespaces are for.
Joe Gregorio: would it be more palatable if the CommentAPI supported an optional SOAP envelope?
Just be aware that anybody who sends you a SOAP envelope is likely to expect you to respond in kind. To help further discussion, here is a Cheetah template for SOAP faults. Invoke it from within any except: block in Python.
James Snell: Almost done with a Liberal RSS Parser for Java... First step towards Jagguar, a three-paned RSS aggregator for Java being built using the Eclipse SWT library. It will run as a standalone application or within Eclipse as a plugin.
Brian Lloyd: I've finally been able to post an initial (experimental) version of Python Scripting for .NET [via Sean McGrath]
First impressions: this looks like the first step towards where PerlNET has ended up: two VMs, two garbage collected heaps, but on the bright side, every existing Python application runs without change or without any performance degradation.
Jason DeFillippo: If you are running any other blog tool that lets you specify sites to ping feel free to add it in and try it.
OK, I'm in. I now ping blo.gs, and blogrolling.com and weblogs.com. It is nice to see that there are now regional services.
What would be really nice is if these services could federate. If this were done, then I could ping one local or topical or fast server which would then send pings on my behalf.
Dare Obasanjo: Your blog is the only one I've seen which supports comments that I tend to regularly post to so whatever you support is what's going to end up in RSS Bandit.
What Joe Gregorio has defined will undoubtedly get supported in Aggie and RESTLog. Apparently, if I were to support it, RSS Bandit would too. I suspect others would follow.
The only thing holding me back at the moment is seeing if ChrisAn and Don Box, et. al. want to be involved.
Steven Noels: Welcome Gump
LOL! What Steven doesn't mention is that gump is nice.
Sebastien Paquet: I believe a critical element to get a sustainable system is for people to get reasonably quick feedback in return for the extra effort expended in creating metadata.
John doesn't get it. Sterling does. It took Sean ten minutes to figure it out. Doug sees the future. Giulio is asking the right questions.
Perhaps it is time for another essay. A short one, this time.
Rebecca Dias is a currently employed as a marketing droid for Microsoft, but I knew her before she was assimilated. In any case, she is starting off the new year right (no, I won't share her age ;-)) with a new weblog.
Don's non-proposal garnered considerable criticism for not providing the appropriate amount of respect for prior art. The following modest change to the header should address this:
<soap:Header xmlns="http://purl.org/dc/elements/1.1/"> <title>My first item</title> <date>2003-03-12T11:02:14Z</date> <creator>Don Box</creator> <creator>Joe Beda</reator> <creator>Tim Ewald</creator> <creator>Chris Anderson</creator> <subject>Rocks</subject> <subject>XML</subject> <description> this is some <xhtml:em>important</xhtml:em> text. </description> </soap:Header>
Aaron Swartz: RSS 0.90, RSS 0.91, RSS 0.92, RSS 0.93, RSS 0.94, RSS 1.0, RSS 2.0, RSS 3.0, ESF 1.0, XFML 1.0, RSD 1.0, FOAF, GeoURL, XHTML 1.1, CSS, Bobby, RSS Valid, CC-licensed, MT-powered. This is what a real weblog needs in our modern world. Raging Platypus, I salute you.
I feel horribly outclassed.
Tim Bray: Hyatt responds to trackbacks...this style of product development makes me much more likely to become a customer.
For those following such things, I've added the following lines to post.sanitize() in order to more gracefully handle paragraph and break tags in trackbacks and comments:
Don Box: Tim Ewald, Joe Beda, ChrisAn and I are trying to get the new format for exchanging items working. Here's a preview of what it looks like now
This format has a number of interesting twists. First, it is document literal XML which Anonymous [presumably Gary Burd] doesn't particularly feel is vi compatible. I'd bet that Don's example was entered in Emacs. Note that the cited xhtml namespace incorrectly points to the same namespace as the blog content.
Like prior iterations from Don, the content is included literally, with no need for encoding. This brings up two questions: if literal XML encoding is acceptable for the body, why is it all of a sudden unacceptable for headers? And how should multi-line headers, like the short description (sometimes referred to excerpts) be encoded?
What is also interesting about this example is that it separates the metadata from the content. While this surprised me, it does makes sense from a SOAP processing model perspective: the one element in the body is intended for the ultimate destination (in SOAP parlance, this is the default actor) and must be understood, the others may be handled by intermediaries and/or disregarded.
I'm not sure what the right split between data and metadata is in this instance. The split that Don, et. al. proposes does have the disadvantage of precluding the ability to the functional equivalent of pingbacks.
Ben Hammersley: The trouble with small pieces loosely joined is that if one goes, the others look really silly.
Joe Gregorio: This version of RESTLog that I am running also supports the CommentAPI. The easiest way to explain it is that you can post a comment via posting an RSS item fragment.
I'm sure that Sean McGrath would think this was just beautiful. I'll definately support this API by this weekend. But before I do, do any other weblog or aggregator tool authors have any comments on the API itself?
Mark Baker: This is such a perfectly RESTful system
I'm pleased to see such a ringing endorsement by Mark Baker of XML Web Services. Unfortunately, we still have a semantic gap where Mark uses the terms "browser" and "web services" in such a limited way, but we can overlook that for now.
Chris Anderson How many people should I expect to host on a 512MB machine?
Mark Pilgrim's and my blogs are hosted on the same machine, and combined get a fair amount of traffic. This currently is a 1Ghz AMD Duron processor w/512MB.
CPU and memory usage was not a problem even when my blog was dynamically generated via CGI for every request.
I'm very curious about your XML formats both for interchange and persistence. Is this documented somewhere?
Based on the recent discussions on verbs, it seems appropriate to make a more clear distinction between verbs as message exchange patterns (necessary, but as a rule, the fewer the better), versus verbs as imperatives (generally to be avoided).
As this distinction is subtle, I decided to sneak up on the topic.
Without further ado: I give you Topology.
Gary Burd: I recommend extending Mombo's comment file format to include more fields than title and body. The attribution information should be moved to one of the new fields and be formatted by the template.
I love it! Gary, how hard would it be for you to come up with a weblogging package that has roughly the same functionallity as mine that you could live with? I'd love to collaborate with you. If you feel likewise, feel free to use as little or as much of my implementation in this endeavor as you see fit.
Could you host a cvs repository on your site? Or would you prefer it elsewhere?
Perhaps we can get Joe to join us. ;-)
Gary Burd: Now that's overkill. For that matter, this entire post is overkill.
Chuckle! Don't be shy. Truth be told, I want to go a step further... make the original file in tempfile.mktemp() and move the try:link/unlink/chmod code to another script w/setuid.
Timothy Appnel: I have a new appreciation for the elegeance and simplicity of XML markup. Not that I didn't have one before its just grown the size of the Empire state building and illuminated in neon.
Obviously, I'm currently embarking on a similar mission, and share Tim's appreciation for XML. My goals, however, are much lower than Tim's: I'm not trying to create a full markup language. I'm applying 80/20 whenever I can: e.g., unordered lists are enough. The times when full functionality is required, I'll personally use full XHTML.
I'm currently looking into textile for inspiration.
Mark Baker: Ok, so let me get it all out, and describe what I believe - and what I don't - about REST and SOAP
Excellent. Organized roughly from least controversial to most controversial. I agree with more than half of this list. This means that there is much common ground.
Rather than dwelling on details, what I believe is that the Internet is a good first order approximation of truly scalable systems. What it got right was a focus on data vs code. If anything, it has too many methods.
IMHO, the model of the future is going to be more closely based on events and alerts than on request/response. Applications will simply know to construct a given configuration of molecules when they receive a given stimulous. They won't necessarily even be aware of who the intended recipient of such "requests" is.
InfoPath is an example of what can be done by tools that simply know how to construct data according to a given specification, without any greater knowledge of semantics or verbs.
RSS has no verbs.
It looks like SOAP is destined to continue to be maligned and misunderstood.
Dave Winer is upset because not everybody limits themselves to his narrow RPC profile of SOAP usage. Non-RPC usage of SOAP isn't new - it was always in the spec. And things that fit Dave's narrow profile continue to interop.
Mark Baker is upset because SOAP permits usages which are not, in his and many people's opinion, well architected. Usages such as RPC. While many of Mark's arguments resonate with me, he tends to throw the baby out with the bathwater. He might as well say that Python is not a good language for building REST systems because it can also be used for RPC.
Meanwhile, where Mark throws up his hands, others are making progress.
|We seem to have another nocturnal visitor.|
The following is now supported in comments:
Clemens Vasters: The "create" story of REST using HTTP PUT is very pretty for this and HTTP GET speaks for itself. It all falls apart when you think about concurrent updates and concurrent deletes. These simply can't exist in such a world. As long as you only create stuff and reference stuff, all is fine.
Obviously, Clemens hasn't heard about the expires header. All you have to do is predict with 100% accuracy when the next POST or DELETE request is going to come in, and all caches will remain perfectly in synch.
It is just a SMOP.
1111111111111111111 looks promising.
I can't make unique titles, but I can make unique links. Try again, and see if you like the results any better. As for your comments on "standards", simply let me know what format you would like me to support and I will see what I can do.
I are a good speler
I laughed so hard, tears came out of my eyes. Thanks Ingo!
Given this, I can only interpret my name being mentioned in the article as a well intentioned compliment, however much I disagree with Mark's assertions of SOAP's implied use and incompatility of this use with REST.
There also is one important aspect that Clemens seems to have overlooked, which I will generically refer to as bindings. When doing SOAP using XML over HTTP, a URI and a SOAPAction are required. Non HTTP and non pointy-bracket serializations of the XML Infoset should also be supportable. A concrete example: a binary message sent over MQSeries may be a vital part of a flow of business process.
Sam Ruby: What I never will understand is how I got so lucky to find someone who would put up with me for so long.
The sweet spot is GET and POST of XML Infomation Sets. REST's content independence and SOAP's transport independence are simultaneously both key strengths and weaknesses of each approach. Both contain speculative features that have not been widely adopted (e.g., DELETE? Content-Negotiation?). The most underrated feature of SOAP is asynchronous messaging.
REST + SOAP is a powerful combination.
It is amusing to see that Network World views me as a REST backer. Thanks go out to Dave Chappell for forwarding me this link.
Thanks Mark, Joe, Simon.
I agree with Matt. I simply wanted to see what wxPython could do.
I find this very amusing.
Forget SOAP. Forget ReST. Consider the following flow. I POST an email address to a URL. An SMTP message comes to that address. In the body of that message is a URL. Issue a GET on that URL. You get a cookie.
It's just data.
It is a very big world out there
The RSS validator has always flagged script, meta, embed, and object tags. But the real fixes need to be in the aggregators. Kudos to Aggie.
I'm not sure what I am going to do with it now, but I've uploaded the source for others to marvel at and/or ridicule.
The problem is that most "content management systems" simply schlep the bytes that are often ill formed HTML into an RSS feed that may be placed in a separate directory or even machine. Then a typical "aggregator" simply throws these bytes into a HTML page without really taking the time to understand it.
Simply put, while HTML is easy to author, parsing it seems beyond the capability of most DIY developers and even many commercial software developers.
The RSS specs (all of them) are actually silent on this. They don't specify what a URL should be relative to (many assume that it should be the site, architecturally, it seems like it should be the feed itself). Since the specs are silent, what matters most is what the tools actually support. Advocacy may help fix this.
Tangentially related, I wonder what it would take to get Tim Bray to add a RSS autodiscovery link tag to his html page? One of the tools that supports it is the RSS validator itself.
Suffice it to say that I thoroughly enjoyed the presentation. In the process he of the 45 minute presentation, Don visually and graphically demonstrated not only the points made above, but also in the process he reinforced a number of entries he has recently made to his weblog: I have a new blog front end, Skin is in the game, and Clemens takes the red pill.
Gordon Weakliem: The most important RSS element: <title>
Looks like I am going to miss Andy, but I am looking forward to meeting with Don and Costin. Others in the greater bay area interested in meeting, simply let me know.
It's time to see how many people I've pissed off lately. I tried harder this year.
Since I use Apache, I can get support for conneg virtually for free through the use of an 'Option +MultiViews'. Unfortunately, as I am currently set up, this only works on the level of what is currently cached statically. This could produce inconsistent results based on the order in which requests are received. Not good.
Another alternative would be to process all requests involving conneg dynamically.
I'm also concerned about the implications of this to other caches. Perhaps Aggie should have an option to turn this feature off in case someone is faced with a less than intelligent proxy which caches?
Finally, I'm skeptical about the existence of client software that can handle multiple formats (not just RSS 1.0 vs RSS 2.0, but RSS vs HTML or PDF). To do this right, the recipient should verify the content type received, and one simply can't rely on this HTTP header for RSS feeds at this point.
Question: from a fiduciary responsibility to one's shareholders and independent of the availablity of source, what is the proper price point for the .NET Framework?
This is a loaded question, and perhaps one that none of us should speculate on. However, one thing you will find is that it is impossible to answer that question without an understanding of the business goals of your organization.