I've taken a 2003/07/01 snapshot of the maximal example of the format previously known as echo. The reason for this exercise is that I plan to start prototyping using this as a baseline. I invite others to do likewise. Let me know via comments of any implementations. In particular, I am interested in templates that others can use.
Obligatory disclaimers: everything is subject to change. Here are my assumptions at this point, also subject to change:
Feed elements
Entry elements
Feel free to challenge these assumptions... they are not cast in stone.
First shots at it: http://philringnalda.com/feed.xml and http://philringnalda.com/templates/feed.xml.txt
Afraid you'll have to live with all local timezones until I write or steal an MT plugin to return a UTC date, though.
Phil, your template only works for valid XHTML, which is not terribly common. Here's an MT template that works for arbitrary HTML:
http://diveintomark.org/about/templates/index/necho-prototype-20030701
Example output:
Let me see if I can get this straight.
Joel:
- Your <feed> should only have modified, not created and issued. The modified should be in UTC and as such not include a time zone.
- Likewise, entry/created and entry/modified should be in UTC.
Sam:
You might want to include a specification for author in here. Also, why is a subtitle for a feed necessary? I don't see that, people might just want to have a title, no subtitle involved. And finally: shouldn't <author> and <contributor> be merged, like <author is-contributor="true"> or <author main="true">?
Created, Issued, and Modified? Isn't that overkill? Also I thought the general consensus was for just Issued and Modified.
A feed level "sub-title" maps to an RSS channel description?
Changing the entry level core text element from "description" to "summary" seems to more narrowly proscribe its possible uses. Can it no longer be used for an excerpt? Or the entire body of the message if I so choose? The naming of things creates expectations.
Although I have no idea if Sam was seriously suggesting Necho as a potential name or not, I like it. A lot. After a quick check, I discovered that necho.org was available. Well... not any more.
In the extremely unlikely event that the name Necho is a contender for the final name then I publicly promise to donate the domain name necho.org for use in whatever way is deemed to be most beneficial to the project.
(In the much more likely case that the name gets passed over, I'll probably just let it expire.)
So... head on over to http://intertwingly.net/wiki/pie/ProjectNameProposals and vote for Necho!
I think that title should be optional. In Joel's feed, the titles are generated. Vast majority of Blogger blogs don't have titles.
If we absolutely want to require seven elements, we can specify "origin" which is a source blog URL or id.
BTW, I'd prefer to allow for non-plaintext titles, while specifying that titles SHOULD be plain text.
P.S. Mostly API related: http://www.intertwingly.net/wiki/pie/BloggerProposals
I'm a somewhat baffled by having 'subtitle' as optional in entries (i.e. input) but required for feeds (i.e., output). Where does it come from if the entry was not given one?
And Necho isn't such a bad name:
"fl. 670 b.c., lord of Saïs, Egypt. He was confirmed in his holding after the Assyrian conquest in 670; he was later taken to Nineveh in chains for plotting to revolt but was pardoned and restored. He probably fell opposing (663) the Nubian reconquest under Tanutamon. "
http://www.slider.com/enc/37000/Necho.htm
Hi Misha,
RE: Title requirement.
I would prefer to see a title required, but it can be empty. Why? Low barrier of entry on one end of the spectrum, and an "encouragement" for new tool authors to follow a practice that encourages such a thing. Good article Jon Udell: Why titles matter
Why can't you do this stuff while it's daylight where I live? I'm right about to go to sleep and find out that I have to implement "NECHO" instead. <s>Have some compassion, man!</s>
Sam,
Looking at existing blog tools (and aggregators), there's one glaring omission: category aka topic aka (dc:)subject.
Here's an echo feed with a subject element included for each entry.
http://www.mystartmenu.com/blog/necho.xml
If I were voting on core elements to support, subject would rank higher than subtitle in importance. As a practical matter, it's like pulling teeth to get people to enter titles, much less subtitles for their entries.
I pinged Sam with this a couple days ago, but I've updated my template to include modified:
main feed:
http://journurl.com/support/users/admin/index.cfm/template/echo
individual entry:
http://journurl.com/support/users/admin/index.cfm/mode/article/entry/557/template/echo
Sadly, it looks like I won't be able to provide an Echo representation of search results the way I can with RSS 2.0. Echo just has too many required elements at this point, and the search engine is optimized to only return the bare necessities.
RSS search feed for "echo":
http://journurl.com/support/users/admin/index.cfm/mode/search/s/echo/template/rss
Oh well... can't have everything.
The src attribute of the content element does not mix with the other attributes (type and xml:lang).
Also, its type attribute feels awkward. If the content is an XML application, using its namespace is more effective; if it's pure text, the situation is obvious. And if you want other stuff in there, why not use the data URI scheme (RFC 2397)?
Author homepage and weblog attribute names are unnecessarily restrictive IMHO (a HTTP URI is just one kind of URI).
Let's please drop the feed-level modified element, this is transfer protocol stuff.
I can't see the reason behind feed:subtitle being required.
I don't even know what it would be for my own blog.
I can't see the reason behind feed:subtitle being required.
+1 ... my blog didn't have one until a few weeks ago, and no JournURL blog has one by default.
* What if we'd like to include a "teaser", "excerpt" or "introduction" in addition to a "summary"?
* What if there are more parties involved but an "author" and zero or more "contributors"? What about an "editor", "publisher", "designer", "content provider", or even a "photographer" like you have in conventional print? Do they become "contributors"?
* How can we support multilingual content? (A story that is available in multiple languages.)
* For single-user weblogs, having to duplicate the <author> block in each entry might be a lot of duplication (and wasted bandwidth).
Chris W,
Are you intending for categories to be feed-specific? That is, the category 'Cheese' in one feed should be considered different to the 'Cheese' in some other feed?
If it is feed-specific, then we have the problem that a single site generating multiple feeds will not be able to (read: not be supposed to) match the categories between feeds.
On the other hand, if they are just some arbitrary global identifier, two authors uses of the same keyword may conflict.
Perhaps category should be yet-another-URI(tm), which (like unique ID) does not actually have to point at anything as long as it is guaranteed to be a unique category URI. For the aid of tools, though, a displayable version of the category should still be provided.
Perhaps some other kind of XML application can be used to return a category list mapping the URIs to pretty names for a given set of feeds? (referenced from the feeds themselves so that tools that can support it can retrieve and cache it for all of the feeds which reference it)
Whatever -- just some thoughts.
I'm concerned about the verbosity of a Necho document, considering the many required elements. My RSS feed is the most heavily trafficed page of my site, and the number of subscribers appears to be increasing on an almost daily basis. I've implemented conditional GET on it, but it is still a huge bandwidth hog as every subscriber sucks down the whole feed every time I post an update (and I frequently post several updates a day). The additional elements required by Necho mean the feed could be significantly larger, and will thus absorb even more bandwidth. Times that by the many, many blogs out there that will eventually be using Necho and that's a lot of bandwidth being burned.
I know that the thinking behind the many compulsory elements is that it makes Necho easier to parse, but I am not convinced that the trade off in terms of the size of the feed document is worthwhile. The added difficulty in extracting information can be mostly avoided by clearly specifying some simple algorithms in the Necho specification document. For example: If [issued] is provided and [modified] is not, consider the issued date to be the date the item was last modified.
I am also strongly opposed to different ways of representing dates being used in the feed. This adds a great deal of extra complexity for implementors without adding any real value, at least as far as I can see.
I have problems with some required elements, too. For example the required author at entry elements doesn't make sense with one-person-blogs. Maybe this would be better with a required author at feed level and optional author at entry level? I could live with the autho-at-entry-level, too, but it feels clumsy.
But what makes problems is the required modification date. I can live with optional modification dates, but not with required ones: PyDS doesn't keep track of modification dates. Publication date should be required to make sure that entries have at least one date. Other timestamps should be optional. Oh, and the default for the timezone should be the same with all timestamps (either all default to UTC or all default to localtime - UTC would be what I prefer).
And the subtitle is something I don't have, too. Ok, I could cook up some (implement it in PyDS or just fill it with an empty string), but that would be cheating, wouldn't it? ;)
I think more elements should be made optional. This feed stuff should be able to be small, if the feed is of minimum character (for example I build RSS feeds out of eBay searches, out of television program and other stuff I like to monitor in my aggregator).
FWIW, the only required element I had trouble with was [modified]. b2 only stores one date per posting, which defaults to the original post date, but can be set to anything. When editing an item, this date is not automatically changed. And if it were changed, my permalinks would break, since they are date-based (/2003/7/2/blah-blah-blah).
The various date manipulations were somewhat complicated by the fact that b2 stores the date in the database as a MySQL 'datetime', in (server time zone) + (configurable adjustment factor) time zone. I find working with those clumsy.
I was also pulling my hair out because PHP's sprintf suddenly decided to append ASCII NUL characters to all my strings, which were actually printed out when those strings were 'echo'ed, which results in invisibly non-well formed XML. What's up with that? Only 'curl [my-necho-feed] | cat -nvet' revealed the problem. I abandoned sprintf and wrote my own, probably buggy, code to format the time zone with signs and leading zeroes.
Are we not going to have any source of resource id? Something that fulfills the role of rdf:about and rdf:resource in RSS?
It's very useful when marking up intra-entry relationships (i.e. comments), and equally useful for the purpose of identifying separate entries when aggregating.
I've removed the created and issued tags from my feed as suggested. Those were in the example at 11:00 pm last night but they disappeared by this morning :)
The "maximal example" doc says really clearly, "All dates are W3CDTF". W3CDTF explicitly allows me to use my own time zone. So I'm going to keep doing that until somebody shows me why I shouldn't.
Well, blojsom (or rather my blog) is now generating necho 0.1 feeds. Here is the feed. Some blojsom-specific thoughts and the current template can be found in this entry. Those are just thoughts on how some optional elements might be supported in blojsom. Changes to the feed will probably occur on a weekly basis as the specification evolves.
It might not be <aerosmith>living on the edge</aerosmith>, but it's a living :)
There appeared to be some consensus on not using <weblog> (with AaronSW dissenting) and using <url role="?"> instead.
<weblog> really doesn't make sense for BBC feeds, for example.
Following recent updates to the content page about site summaries vs. syndication, I've created two feeds, one as metadata (site summary) and one as syndication (embedded content):
http://bitsko.slc.ut.us/blog/index.site
http://bitsko.slc.ut.us/blog/index.necho
The email element should be added to the author elements, if this is a "maximal" feed. It was in the author page on the wiki, but never made it over to the example feeds.
Can you add it to your samples, Sam?
I am missing an image or logo element. Both in the RSS readers and in my (IE4 CDF revival) it is quit usefule to distinguish the feed visuallly.
Isn't it better to discuss a bit loanger as now the empale feeds look really pathetic compared to RRS 2.0 and RDF-RSS 1.0.
A few perfectly good element names channel, item, description were changed in feed, entry and summary, big dela.
Some elements are not in like category, image...
A Useless new sub-title element is introduced.
Boys and Girls what are we doing. Isn't it time we get some more rational experienced people into this to see what is really needed.
A maximal example, come on.
We need to do alot better otherwise better fiddle a bit more with RSS 2.0 and include some needed items with a namespace.
Cybarber
Re: bandwidth use
I think Simon has a point here. It's getting a bit verbose, and I know for one thing that I choose to use RSS 0.91 because it was just simple, didn't need too much stuff. Keep It Simple Stupid! Having some optional tags really doesn't make it too hard to parse, in my opinion.
The whole publisher, editor, graphics-guy thingie should probably be done in an extension (ie in another namespace).
Also, the <url role=""> seems to be an improvement to me.
I'm impressed how simple it is to take the code to produce an RSS1.0 feed and cloning it to produce a Necho 0.1 feed (grabbed from Mark Pilgrim's feed example above). I've done this with my blog already (Yeah, I know there'll be changes - but what the hell *g*). I'm using PHP and templates.
PHP template file: http://www.isolani.co.uk/isoBlog/isolani.necho
http://www.isolani.co.uk/blog/index.necho is the main one, plus I have ones for all the channels. Links at the bottom of my blog page. (Oh, I cloned a quick Necho0.1 button image for my blog feed links, please feel free to grab it and reuse)
Simon Willison writes:
I've implemented conditional GET on [my RSS feed], but it is still a
huge bandwidth hog as every subscriber sucks down the whole feed
every time I post an update (and I frequently post several updates a
day).
What percentage of clients use conditional GET requests?
[A]n optimisation for Necho feeds that eliminates the need for
duplicated author information in every entry, described here:
http://intertwingly.net/wiki/pie/EchoFeedWithAuthorRefs
IMHO, author information should only be referred to by URI.
I'd change a few things:
And add these:
I really think too many elements are required at the moment, leading to a feed which is rather verbose.
I'm inexperienced in the world of feeds/RSS etc, so forgive me if I'm talking nonsense.
For the record, I think Necho isn't brilliant, but then I always thought Yahoo! was pretty stupid, so what do I know?
Greg Reinacker writes:
The email element should be added to the author elements, if this is
a "maximal" feed. It was in the author page on the wiki, but never
made it over to the example feeds.
The name is (again) unnecessarily restrictive: there are more URI schemes that could do as content/value here. IMHO, "contact" (or some such) would be more appropriate.
But then again, this sort of information shouldn't be be part of a feed.
Here's a stab at it from me:-
http://jessey.net/blog/necho.xml
I don't like the idea of dumping an entire entry into a block of CDATA. I want my punters to visit my actual weblog, so a summary seems more apt.
(I didn't know where else to post this, so I'm sorry if I'm spamming your comments)
Holy cow but you guys are going to get creamed when some commercial content management system decides on a syndication spec to give to all of its customers. I see Vignette coming along and blowing you guys away with a flick of their wrist.
You must, must, must (I can't emphasize this enough) include some sort of authorization/encryption/challenge-response format for individual feeds, at the very least. Content syndication, at least at the corporate level, must take place within a secure environment, and I don't mean just slapping on SSL to a feed reader and calling it a day. Every single piece of data should have the ability to be encrypted in any number of formats, whether 3DES, Blowfish, RSA, PGP, etc. Companies will demand at least this level of security before they use your solution to syndicate content.
You must, must, must (again, I can't emphasize this enough) create some sort of delta feed, to be able to tell what is new in your data stream without having to download 100k+ of a syndication datafile. Imagine a feed with 100,000 subscribers, each subscriber doing a refresh every ten minutes, having to download 100k. You're transferring 10GB of traffic every ten minutes. That sounds an awful lot like a reverse-Marimba to me. If you had a very-stripped-down feed that showed the deltas in your data within the last, say, (user-mandated time period), you're going to incur much less traffic.
You must, must, must (this sounds repetitive) allow for in-line data, whether encoded as Base64 or otherwise, and filtered, variable based upon the client. Static files are great, if you live in the year 1994. You may argue "that's up to the software to determine" but I would say: what of JavaScript? Here is a language that determines the format of the HTML page being displayed, based in part on the client. As an aside, allow for device detection as part of the feed. My cellphone must absolutely get a different version of the feed than my newsreader. In-line HTML is worthless to a cellphone.
These may be fairly ignorant statements-- you may have already covered all of these points, or you may just push all of these ideas off on the Ben Trotts of the world who get to go through the hell of implementation. I'm looking at RSS as an end-user and I
see this group going down the same path, making the same mistakes, that RSS made. This format should be an evolution from RSS, not a duplication. Imagine how CSS and the DOM has changed web development versus the year 1997 when we were struggling with embedded tables.
Thanks for reading my rant.
Mark,
I think you have valid concerns (security, bandwidth), but they are outside the scope of the core spec. How a particular implementation decides to secure, encrypt, or produce its feed is entirely up to it. If you are going to encrypt something, encrypt the entire feed from beginning to end and have the receiving client decrypt it. Currently, I am not aware of any aggregator that does this, so you'd be rolling your own solution from back to front.
We're trying to design a file/message format that utilizes the best features of previous formats while overcoming their limitations. The scope of this project is to learn from the mistakes of previous implementations and unify APIs that have evolved independently but which all do the same thing.
We're not in the CMS business, and Vignette is welcome to extend this format, as is anyone else. We're just doing this 'cause we love the technology.
"We're not in the CMS business"
I disagree entirely. Movable Type is a CMS. Blogger is a CMS. Radio is a CMS. Unless you feel that weblogs aren't content?
Encrypting the entire feed isn't a viable option, in my opinion. Some clients should be allowed to see some data, while others should be allowed to see other data. For instance, I may pay Reuters a certain amount per month for a "base" syndication feed. You may pay Reuters a larger amount of money for a "deluxe" syndication feed. How do you distinguish between our levels of syndication? Generating separate XML files per client doesn't count; that defeats purpose of easy-to-use syndication.
I would ask everyone to not go into this process thinking "how can we reinvent a weblog text file format" but "how can we create a fully-functional content syndication format". Content isn't only text from a weblog.
"Start lightweight and tack on extensions" is a good mantra only if the base format can handle the extensions being tacked on. Challenge everything. Is the "one text file" format sufficient? Is the "plaintext published by weblog utility" way of thinking sufficient?
One thing I neglected to mention: I haven't seen any sort of thought being given to content expiration, either. You may say "content doesn't expire, and shouldn't" but I refer you back to my example: if I pay for a weekly syndication, and you pay for a monthly syndication, how does a company tell me when to remove the data I've syndicated?
Thanks again.
Mark:
<weblog> really doesn't make sense for BBC feeds, for example.
Nor should it. I'd encourage people to have another look at the roadmap... Echo is supposed to be a weblog-centric format. The BBC will and should continue to use more generic syndication formats like RSS.
I have a sneaky suspicion that somewhere in the depths of the wiki, many people are forgetting this little detail. I hope someone reminds them ASAP.
Mark Beeson:
You may pay Reuters a larger amount of money for a "deluxe" syndication feed. How do you distinguish between our levels of syndication? Generating separate XML files per client doesn't count; that defeats purpose of easy-to-use syndication.
Mark, try reading that again a couple times. You want support for per-item encryption and multiple levels of subscription, but you're concerned that multiple XML files aren't easy to use? :)
I would ask everyone to not go into this process thinking "how can we reinvent a weblog text file format" but "how can we create a fully-functional content syndication format".
See the roadmap. Echo is a thing for weblogs.
Actually its seems it would be the opposite way around:
Anatomy of a Well Formed Log Entry
http://www.intertwingly.net/blog/1472.html
Noticed in Sam's announcement he does not use the word weblog once. He carefully used the word log NOT weblog.
Someone superimposed weblog along the line. I have been working under the impression that this syntax goes beyond weblogs.
I see no reason why this syntax is not applicable to a newsfeed.
"...but you're concerned that multiple XML files aren't easy to use?"
Yes. Do you want to generate 100,000 XML files, for 100,000 paying subscribers? I have a sneaking suspicion that scalability isn't really being taken into consideration here. Again, I would beg of everyone to not push that sort of functionality onto the software developers, because then we'll all be duplicating work that can be easily taken care of with a robust syndication format.
I'm also hearing that this is solely for weblogs. I find that to be an incredibly short-sighted vision. Design a good format, and weblogs will use it. Design a great format, and everyone will use it.
Mark:
In a previous life, I worked for a major search engine. We served well over 100,000 dynamically generated search result pages per day; although I'm not sure of the numbers, we may have done that many XML pages for paying customers. It wasn't all that hard.
I may well be missing something that makes this a bigger scaling problem -- comments?
Timothy:
Noticed in Sam's announcement he does not use the word weblog once.
I hate to be the jerk who points this kind of thing out, but he uses it right up front, in his second sentence.
"These are essential characteristics of a online Journal or weblog."
But that's beside the point, really. All those "signatures" on the roadmap page are attached to a document that makes it clear the mission here is furthering interoperation between weblogs. If other uses can be found after-the-fact or via extensions, that's great... but such uses are secondary at best.
Then, if the <author> is the author of the weblog, why do you need a <weblog>?
Further, the FrontPage (which is where many people start on the Wiki), states "The EchoProject is an initiative to develop a common syntax for syndication, archiving and an publishing API."
If it is a common syntax for weblog syndication, archiving, etc., then shouldn't it state that in the introductory paragraph?
I've created a somewhat "funky" example feed of how a Necho feed could be used for program listings.
The or differences from the plain-vanilla 0.1 Necho feed are:
The general idea is that a generalized Echo aggregator would provide a user with a normal program listing, while an specialized tool could read the same feed and schedule playlists. Think TiVo.
Mark writes:
"Do you want to generate 100,000 XML files, for 100,000 paying subscribers?
I have a sneaking suspicion that scalability isn't really being taken into consideration here. Again, I would beg of everyone to not push that sort of functionality onto the software developers, because then we'll all be duplicating work that can be easily taken care of with a robust syndication format."
1) There's nothing about forced serialization to disk in the spec. All of that XML is just rows in a table until it's serialized out to RAM.
2) You can encrypt your entries how you like, using CDATA. Knock yourself out with that crazy DRM action too, while you're at it. Add all the timeout attributes you feel like.
Not to be rude, but you clearly haven't thought this one through. Extras used by .0001% of the clientele (less, but I'm being charitable), like encryption (!!) or DRM (!!!!) are perfect candidates for external modules. I can't wait to be able to send people embedded perl fragments for them to auto-execute, but you won't see me put that in the wiki.
Disclaimer: I once stayed over for a weekend at Bryant's house -- my ideas are his, and only his.
I'm confused, and it surely comes from not ready carefully enough, but there are a whole lot of places to be reading to keep up to date on this these days.
Will the new format allow for full content to be included? Sam's list of <entry> specs at the top of this page doesn't include any reference to the body, the meat, the full content. I'd presume there's at least a 50-50 split of end-user preference for descriptions vs. full content.
Lex: yes.
I also think you're right about a near even split. I don't know if there will be different profiles for each, or if the separating of "description" into "summary" and "content" solves the problem neatly.
Martin,
I think at a minimum, supporting existing categories (by name) should be supported (as an optional 1+ attribute). As you mentioned, these would be feed-specific.
But I think your idea of using a URI, so as to fit in some sort of "shared" categorization makes sense, too. Perhaps supporting both, through an attribute, uri=true or somesuch... Of course, with URIs there's the problem of what to name these things in the client app.
Looking at the example again, I hadn't realized that there's already been some work going on in this area, "Easy News Topics" See http://matt.blogs.it/specs/ENT/1.0/
Maybe that can be used directly, as an extension to necho. Dunno. Sifry has a little analysis of this idea here: http://www.sifry.com/alerts/archives/000282.html
NECHO conversion to CDF RSS1/2 to CDF and RSS2 to RDF)
I had put a message in the well-formed XHTML group but here is more appropiate.
Based on Yasser Shohoud's and Sjoerd Visscher(unchanged) XSLT sheets, I made a demo page.
Showing how I work with the ancient IE4 Channel Definition File(CDF) format under WIndows XP proff.
I have uploaded Sopolsky's, Pilgrim's, Watermasysk's, Burton's, Isolani, Bersvendsen and the Maximumtemplate itself to my site.
For transformation I changed the encodings to utf-8 and deleted the namespace references.
In the demo page above necho-files can be selected in the Selectbox and transformed to CDF. transform to RSS2.0 and RDF(Rss1.0) I'll do this weekend. (page starts with a SMIL animation showing an image of Sam Ruby's RSS feed in CDF on my PC, you need IE55/IE6 msxml3.0)
http://cybarber.ath.cx/kanaal/TestingwithSources.htm
Cybarber
NEW name for non-Echo.
As we will not use 'ECHO' nor 'NECHO', I propose the following name for the new RSS-XML vocabulary:
Synchronized Aggregated Messaging
or for short
SAM
This will give at the same time credit to the big motor behind all this Sam Ruby
My SAM to CDF and tomorro my SAM to RSS2 demo page is online at:
http://cybarber.ath.cx/TestingwithSources.htm
Cybarber
Name Proposal for not-Echo
updated proposal
I'll stick with
SAM
but I was pointed out that is better to use Syndication(ed) instead of Synchronized. Instead of Messaging maybe Markup is better,
so
S(yndication) A(ggregation) M(arkup)
Cybarber
We admire the conformance to the ISO 8601 standard, but would appreciate it if the time zone would remain optional, consistent and preferably based on the posters local time zone (oh and no shortcuts, always as +00:00).
Thanks and good luck,
@Quest WebDesign http://www.atQuest.nl/
I've added support for (not)Echo to BottomFeeder - http://www.cincomsmalltalk.com/BottomFeeder. I've also added not Echo formatted feeds for my blog:
blog: http://www.cincomsmalltalk.com/blog/blogView
feed: http://www.cincomsmalltalk.com/rssBlog/necho.xml
comment feed: http://www.cincomsmalltalk.com/rssBlog/nechoComments.xml
I've added support for (not)Echo to BottomFeeder - http://www.cincomsmalltalk.com/BottomFeeder. I've also added not Echo formatted feeds for my blog:
blog: http://www.cincomsmalltalk.com/blog/blogView
feed: http://www.cincomsmalltalk.com/rssBlog/necho.xml
comment feed: http://www.cincomsmalltalk.com/rssBlog/nechoComments.xml
I have cooked up a formatDriver for necho in Radio Userland.
Mark, thanks for the Radio bug report. The bug has been fixed.
Note that this bug affected only outbound pings from Radio, and not pings from Manila.
Mark, thanks for the Radio bug report. The bug has been fixed.
Note that this bug affected only outbound pings from Radio, and not pings from Manila.
Jake: excellent responsiveness, as always. Bravo.
Having let my Radio subscription expire, I am not in a position to test this for myself. Perhaps you might want to ping this entry to see if my implementation of trackback interoperates with the updated Radio?