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?
Hol' up.
Does your blog support this RESTLog POST thingamajiggy? If so I can hack support for posting comments to your blog in RSS Bandit in an hour or so. I only need some way to determine whether a URL supports RESTLog posts or not instead of blindly posting to URLs that don't support it.
Dare: it will by this weekend. And Joe is soliciting comments on what element should be placed in the RSS feed to indicate what endpoint should be used to respond to a given blog entry.
I will not only support description but content:encoded. Furthermore, if Don Box, Chris Anderson, or whomever care to specify a <content> element into which well formed XML is literally placed without encoding, then I will support that too.
I need some indication in the RSS feed or on the page identified by the URL that it supports RESTLog POST for submitting comments. I don't want people composing lengthy messages and posting them to Wired or Don's blog only to get a 404.
Dare,
At the end of the CommentAPI spec is a section on auto-discovery. For HTML it uses a link tag, just like a link tag is used for RSS auto-discovery.
I'm accepting ideas for how to present the same info in an RSS feed.
Dare, I think you and Joe are agreeing. What neither of you have yet to do is specify the namespace, name, and attributes to place on this RSS element.
Sam Ruby: New Comment API: Dare Obasanjo: "I need some indication in the RSS feed or on the page identified by the URL that it supports RESTLog POST for submitting...
[more]
Trackback from snellspace
at
Comments and TrackBack = WriteBack.
Joe Gregorio posts about his Comments API to RESTLog. This is great, but what I'd really like to see is TrackBack and Joe's proposed API to merge into one. Remember TrackBacks are Comments are TrackBacks. In related news Rael Dornfest releases WriteBack for Blosxom 2.0....
[more]
Trackback from tima thinking outloud.
at
Joe, personally I prefer James's suggestion that this namespace be associated with the wellformedweb than with any one particular weblogging implementation.
That being said, whatever emerges, I will support.
Joe: That works for me. It'll be a week or two before I'll get a chance to update my blog to support the new API (actually planning some major changes soon) but in time I'll fully support this as well.
Let me throw out a few thoughts because while I think this is great it doesn't feel quite right.
I mentioned this in my weblog post earlier today[1]: This is really great stuff, but I'd much rather see comments and TrackBack pings merge. Rael Dornfest is calling the combination WriteBacks.[2]
In his recent O'Reilly RSS article[3], Ben Hammersley uses the existing <annotate:reference> for point a comments feed back to its original entry. Couldn't the same be done here? The module documentation[4] seems to indicate this was its intended use.
I did some checking and the namespace of comments is not in use. Nor is WriteBack (see previous mention.)
I realize this flies in the face of the annotate module, but I'm not hot of the wfw prefix particularly if its only for one element. Besides, when I read the wfw I think of Hulk Hogan and The Rock for some reason.
You may be seeing something I'm not, but as I read the Comments API documentation, it's set up so that it DOES merge Comments and Trackbacks. Look at the samples, there is a clear example showing what a Comment API based "trackback" would look like.
Re: <annotate:reference> looks like it might be applicable, though a bit of a stretch. It looks like it should point to the web page that contains the form you enter your comments on, not the target URI of the POST in that form. In the case of the CommentAPI the URI referenced is going to be the target of a POST, not a GET.
It would also require adding in two namespaces, not just one. You would have to add the annotate and rdf namespaces for that one tag. There also isn't a proscribed method to differentiate between all the possible uses of <annotate:reference>. The spec mentions, "crit, Usenet, and most web-based discussion groups." but gives no way to specify which of those services the "rdf:resource" attribute is pointing to.
James: I'm not asserting that Comment API is far off from TrackBack. I certainly considered Joe's original proposal when I wrote up my TrackBack NG proposal.[1]
What I see missing is backward compatibility with TrackBack. Also, current TrackBack implementations do not support Joe's proposed interface. As I've written, I think TrackBack <b>should<b> support something like it however that's not my call to make. I'm just one person trying to be a catalyst for further discussion.
If merging is what we are trying to achieve, why not use the TrackBack Module for RSS 1.0/2.0 module[2]? It could be used to indicate the URL of the "commenting" system. Incidentally its quite similar to <annotate:reference>, but a bit more specific. The module does offer an RDF-free alternative.
Joe: I have issue with XML serialization of RDF, but there is too much useful prior art (modules) that use it to completely avoid it. I've resigned myself to having to declare the rdf namespace. I'm just happy its not in my face in the core elements or spec. (ie <rdf:li> rubbish.)
I think in the spirit of not reinventing the wheel this course would be successful given the install base and momentum of TrackBack then create something new -- even if it's based on RSS. Look how far Pingback got trying to reinvent the wheel instead of advocate change.
I believe that one of the Universal Laws of Good Technology is that one should never be afraid to reinvent the wheel... several times if need be... as long as we continue to move in the right direction. Trackback is good. Trackback could be made better. But why not make it better by simply reinventing it?
One of my favorite toys as a child was my etch-a-sketch. after creating a masterpiece, I'd sit and admire my work for minute then shake the hell out of it and start all over again.
It would be useful if the auto-discovery contained an attribute that specified whether the site allows for html in the comments.
Aggregators can then use this to enable or disable rich editing of the comment prior to sending it.
But why not make it better by simply reinventing it?
Because there is a large install base that is still growing -- rapidly.
I understand what you are getting at. And there are times where I side with your view. Track down my past commentary on topics such as (X)RSS and WSIL and you'll see signs of it. However given these past experiences and having studied TrackBack in great detail, this is not one of those times.
The ability to write aggregation code against the Comments API is going to be great for blogdom, in my humble opinion. Many thanks to Joe and Sam for pushing this idea forward.
Now what about closing the loop? Has there been any discussions about how to best expose individual comments-trackbacks-pingbacks to aggregators. (I could certainly have missed such discussions. If so, please pardon the newbie and pass me a URI.)
Some obvious options for exposing comments and comment-like data include: inline with the RSS, as a distinct RSS feed that is pointed to by the RSS item and as an extension to the Comment API itself.
Has anyone already done one or more of these? Any thoughts on which options would be preferable?
Joe: take a moment to see what RSS feeds I already provide. You can subscribe to all comments on this entire blog (which includes pingbacks and trackbacks and email and excerpts) in any of several flavors, or you can subscribe to an individual blog entry.
When it rains, it pours, implementations, that is.
First, I haven't been posting much because my day job has been keeping me busy. How busy? Well a normal week might include one special project/product. This week saw 5. Enough said. But, I come out of this crunch to two nice discoveries. First, as...
This is the current list of CommentAPI implementations, be they client or server side. Me The Python implementation of RESTLog, Bulu, supports the CommentAPI. Sam Ruby Eric Vitiello Jr. Simon Fell Dare Obasanjo Has implemented CommentAPI client...