Scoble:
Several things...
(1) What Google announced was switching over from their Blogger API to the Atom API. The Atom API and Atom the Syndication Format are not one and the same.
(2) If you're talking about Sam's XPath stuff, there's nothing particularly, er, Atomic about it. If you've got an XML datastore, you can run XPath queries against it... that datastore could be Atom, RSS, an XML-DB, or whatever. I prefer SQL, personally, but that's just me. 
(3) There's an argument to be made that Google's (and Six Apart's) support makes adding Atom API support to a blog app/client something to seriously consider. Atom feeds, OTOH, aren't nearly as significant... when you get down to it, Atom feeds only exist to provide a data model for the API.
We've got perfectly good syndication formats already on the market.
If MS went ahead and created their own, they would be suspected of attempting to strangle the exisiting formats.
MS should sit back and go wherever the market takes them.
Michael, I don't see MS changing their internal company motto to "Where will the market take us today?". If the Atom guys can come up with a competitor for RSS in order to serve their purposes better (and honestly, what other reason is there?) then why shouldn't MS do the same if neither Atom nor RSS are good enough?
I don't think they should. I think the resources would be better spent embracing, extending and exploiting instead of re-inventing the wheel.
IMHO, the Atom initiative is dead in the water. Diffusive nature of Wiki, lack of strong leadership, and unsavory obsession with REST are some of the major reasons.
So called Atom specs are just proposals by certain active participants who are 'first-movers' with 'loudest-voices'. Even worse, they are just RSS format with different element names. API-wise, it's poisoned with REST ideals.
My advice to Microsoft is to hold off on supporting Atom until the need to support it becomes obvious. As I see it, the need will never materialize.
As to Google, I am not sure if their attempt to influence the core blogging technology stems from the need to protect itself from the obvious dangers blogging represents to Google or wllingness to cater to Evans' vanity.
Instead of creating a new format support both formats in the short term and get both groups to take the formats through a standards process so RSS/Atom can finally be one format. If this does not happen, not only will there be RSS and Atom but many more, and just how many formats can the industry support.
Google just entered the semantic blogging space, via lossless conversion of Atom to RDF. Add support for the RDF dialect FOAF, to encode links between blogs, and query tools, and a precisely searchable/navigable blogspace is enabled.
Very good for ad placement...
So watch for Google to output ad management tools based on Open Office.
And a whole Ebay-style ecosystem to use the tools.
And lots of developers to build out the toolkits...
Especially (college) student developers, who will, along with their peers, use Google as both a Friendster substitute and a professional reputation enhancer.
All told, then, Google's Atom support sets up a dynamic wherein Google and open source become VERY mutually reinforcing...
To develop a better intuition re: how big this ecosystem might get, and fast, see this Forbes article about Ebay's ecosytem:
http://www.forbes.com/home/2003/
...partner=newscom
Key excerpt(s):
"Recognizing that the online auction giant can be an easy way to offload millions of dollars worth of excess inventory, companies like Sony (nyse: SNE - news - people ), Fujitsu (otc: FJTSY - news - people ), Sharp (otc: SHCAY - news - people ) and Texas Instruments (nyse: TXN - news - people ) are setting up shop on eBay (nasdaq: EBAY - news - people ), bypassing the liquidators to sell directly to eBay's 86 million registered users.
They aren't doing it alone, though. These firms have turned to Accenture (nyse: ACN - news - people ) and its Connection To eBay unit, which helps large retailers, manufacturers and distributors sell high volumes of excess inventory through the eBay marketplace.
Run by Robin Abrams, former president of Palm Computing, former
(cont.)
...president of Palm Computing, former president and CEO of VeriFone and former senior executive at Apple Computer (nasdaq: AAPL - news - people ) and Unisys (nyse: UIS - news - people ), Connection To eBay employs 92 people based at eBay's San Jose, Calif., campus. It makes the following pitch to manufacturers: Within 17 days, it will build a complete eBay distribution channel, handling everything from auction strategy, listing setup and management to pre- and post-sale customer support, checkout, order management, warehousing and shipping. So far, the service has drawn 60 customers.
...
Hot on Accenture's heels is SAP (nyse: SAP - news - people ), which in June unveiled its own service to provide auction management, sales, order fulfillment and financial processes to help companies offload excess merchandise on eBay."
Microsoft should just create its own, make it the default standard through wide distribution, and stop all of this nonsense.
I'd prefer anything over the hack that was RSS. I would also trust Google to create a format more usable for non-Microsoft users than Microsoft would.
Don:
"So called Atom specs are just proposals by certain active participants who are 'first-movers' with 'loudest-voices'."
... and this differs from the rest of the blog "standards" world in what way?
-- Yoz
The one thing I haven't seen mentioned yet in this thread is that Atom includes blog authoring functionality as well, which is important in getting vendor independent/multi-blog tool clients like w.bloggar out the door.
Also, it stands to reason that IBM will be a huge presence in the Google ecosystem. Along with HP, Novell, Sun (esp. re: Open Office), ...
BillSaysThis: shouldn't the Atom API be considered separately of the syndication format?
Isn't the Atom syndication format the only part of the overall API that would "compete" with RSS? From what I've read (mainly Mark Pilgrim's and Sam Ruby's stuff) it seems like a more feature-complete and secure blogging API would be a good thing. If Atom ends up providing a better blogging platform, why would one want to throw out the baby with the bathwater?
Would it really be that much work for aggregators to support both Atom and RSS feeds? We live in a heterogenous world, so why not have competing feed formats as well? If the Atom format is really superfluous, feed readers probably won't prefer it.
Alex: the problem is now my blog will have even more icons on it, which will confuse even more readers.
And, personally, I could see great value in having a system that worked better than either RSS or Atom. Imagine a Longhorn-only syndication format. We could do really great integration.
Right now RSS wouldn't pass any of the end-user-testing we do here at Microsoft. Why? Ask "average Joe or Jane" what that XML icon does. They'll click on it, see the XML, get confused, and swear at their computer again.
Now, imagine a new syndication format that brought up a page that showed what a news aggregator was, and explained how the system worked and why it's more productive.
Neither Atom nor RSS can do that.
So, why shouldn't Microsoft see that syndication is a big deal and then come out with its own format that is better than the other two?
Yoz, the situation is different from what you are hinting at. Early sketches by a few members of a group is being peddled as the product of the whole group without approval and despite unfinished discussion over major issues.
Alex: OK, but then why doesn't Google do the right thing and support both formats? After all, that's probably what Microsoft is gonna do. Google says "do no evil" in its business plan. Seems that Google is not supporting a format that thousands of sites are already supporting. Isn't that evil? Why not?
Now, imagine if Microsoft was doing what Google is. Still not evil?
I also find it interesting that NO ONE has sold me on the advantages of Atom's syndication format. Come on, isn't there ONE reason why Google is supporting Atom? (And don't bring in the API, that's a separate issue).
"Now, imagine a new syndication format that brought up a page that showed what a news aggregator was, and explained how the system worked and why it's more productive."
Robert: You're fired. You can't reveal stuff that Microsoft plans to patent. Clean out your desk and leave the premises. And don't take any digital camera pictures of any delivery vans, either.
Robert: I can't speak for Google. If their users want to publish RSS feeds (and hence broaden their potential readership base, presumably because of the limited Atom support in current aggregators) they should request the feature.
I'm seeing this as a Coke/Pepsi, CBS/NBC/ABC thing. If my feed-reading app supports Atom but not RSS, or vice-versa, I would go find one that supports both if I want to subscribe to sites that have chosen one format of the other.
I'm just a blogger and not much of a programmer, so I probably have a much different perspective on this than Microsoft or Google.
Robert, the only reason is Evan Williams. He and Dave just don't get along. As to rest of Google, I am sure they don't care.
I have not followed closely, but aren't the advantages that some ambiguousness was removed regarding base hrefs and relative links. I am not sure how it got resolved, but also timestamps should be improved upon ( created, edited, commented, proper understanding of timezones, etc. I am not sure they got all that, but that is what a syndication format should do. Personally, I would prefer if MS brought in some of their best people to come up with a more comprehensive format, with namespaces, and engineered for extensibility, as well as tools that created that format, read that format, validated that format, etc.
Jarned: heh.
Don, I think your theory is at least half wrong. I like Evan Williams. I would happily talk with him any time. I've tried over and over. Basically I've been trying to reach out to these guys any way I can. I hold no grudge. I just want a common format we can all use to syndicate. If you need a feature that's not in RSS, create a namespace. I've just asked that people not use an element in a namespace when there is already one in the core that does the same thing. Note that I used the word "ask" not "force." I never had any power to force anyone to do anything, as has been noted elsewhere. And to Yoz, the reason it matters if Atom is an open process is that it was founded on the promise that it would be. That was to be the key difference between it and RSS. If it doesn't achieve that goal, then what exactly does it add?
Now to Scoble, the reasons why Microsoft should continue to implement RSS 2.0 exactly the way they have been doing it.
1. You're in good company. All the other major tech companies and publishers are using RSS 2.0. This includes Sun, Oracle, Apple, Rolling Stone, NY Times, News.Com, Yahoo, AOL, Ziff-Davis, the National Weather Service, the state of Arkansas, etc etc. It's a roaring format. RSS is a very safe choice because we know what it is and it isn't going to change.
2. RSS is extensible, so if you have a need in the future that we haven't anticipated, you can easily add your own features.
3. We know that Microsoft likes to Embrace & Extend, and we planned for it. It's the respectful way to compete, doesn't invalidate the work of those that came before. Sort of like the golden rule of technologists, do unto others as you would have them do unto you. That Microsoft didn't immeditely reinvent RSS is a sign that Ballmer's new philosophy is taking root.
4. We prob
Ooops, I guess there's a length limit on the comments here. Oh well, I forgot what #4 was. But #5 was if you use RSS I'll help spread the word. I'm willing to use my pulpit to help my friends. I do it all the time.
This entire discussion is based on a misconception. The original question was "Why does Blogger support Atom and not RSS?" But Blogger does support RSS, and has for months. See http://boingboing.net/rss.xml for an example. I believe (although I could be wrong) that they actually support multiple versions of RSS (there are at least 7), and let the user choose from a drop-down which type of feed they would like. Why is it so difficult to comprehend that they are now adding another choice to this drop-down?
Mark, please, to say there are at least seven versions is misleading. The 0.91 to 0.92 to 2.0 path is smooth, they are compatible versions. You could put a 2.0 version number on a 0.91 feed and it would be a valid 2.0 feed. I'm sure you know this. I wonder why you keep spreading this idea, actually I think I know -- your case for Atom is so weak you have to mislead people about RSS. I'll tell people what you're doing every chance I get Mark.
More on Blogger's RSS generation is here: http://help.blogger.com/bin/answ...r.py?
answer=290
Not sure how current this information is since it references Blogger Pro, which no longer exists. Also I can't find a reference to the drop-down for alternate formats, so I could be wrong about that. I swear I saw it at one point, but maybe it was just a proof of concept. Anyway, Blogger has supported RSS for a while, and soon ti will also support Atom. Next question?
Once again Dave is using the misleading word "compatible" to describe 7 wildly different specifications that are all called "RSS". There are even two versions of RSS with the same version number (0.91) which are different in multiple ways! They don't even have the same elements in common, and some of the elements they do have in common have different semantics! (For those of you following along, I'm referring to the textinput/textInput debacle, as well as the 0-based/1-based skipHours debacle.)
Here's an incomplete and out of date (but still useful) chart that lists 5 versions of RSS. It hasn't been updated for RSS 2.0 and doesn't acknowledge the different RSS 0.91 versions, but it's correct other than that. 5 + 2 = 7.
Hmm, my link got eaten, let's try again: http://radio.weblogs.com/
0101679...ickSummary.html
Mark: the question isn't what Blogger Pro will do (especially since it no longer exists). The question is what will regular old free Blogger do. Right now aren't there one million blogs over there that don't have any kind of syndication?
This is exactly why what Google does is so important. It makes a statement to the rest of the industry.
Evan: can you explain, in layman's terms, why you support Atom and not RSS?
Robert, you're at best creating a conflict where there isn't one and at worst intentionally spreading FUD. Blogger (the pro version, at least) does support RSS. Evan has an RSS feed, and I subscribe to it. Additionally, the simple act of one guy creating and serving an experimental Atom feed doesn't mean Evan (or Blogger, or Google) is committed to Atom and will shun RSS.
Mark: so far Microsoft has supported RSS 2.0. One format on this side of the fence. Going forward it looks like we'll need to support RSS 2.0 and Atom because we'll need to be compatible with whatever Google does. Hey, that's turnaround, isn't it?
Now the question is, since there are two formats (er, eight, as you point out). Why shouldn't Microsoft do its own to support its own customers better? I could see a Longhorn-only syndication format, for instance, that would give a ton of improved features and application & browser integration.
I can see it now. The Weblog of 2006 will have three icons. RSS; Atom; and MSRSS.
Okay, you're still spinning.
Let's talk about Atom, since that's the subject Scoble asked about.
How many specs does Atom have Mark?
Paul: Evan could very easily disclose what Blogger's future plans are regarding RSS and Atom. The fact that he put an Atom feed up on his own weblog is a major hint to the marketplace that Google is going in the Atom direction.
Imagine if I did that here and demonstrated a new "MS_SYNDICATION." You all would be calling me evil for trying to do something that an existing format already does.
(raises hand)
Actually, since you're asking, I have a question.
However, it's not to Mark. Rather, I'd ask, maybe rethorically, "Why is it that Mark has to answer what Blogger does or doesn't do?". We should note that this whole discussion is based entirely on a single link posted by Evan, with no comment attached to it whatsoever. There is an implicit assumption that Blogger has dropped RSS for Atom, which Mark disputes (Mark says it will "also" support Atom, while Robert's and Dave's presumption--and not completely baseless IMO-- is, I think, that they will switch to *only* supporting Atom).
My question, rephrased, would be, "Why can't Blogger come out with a simple, clear statement that explains what exactly will they do?" Something that says: This is what we plan to do. These are the formats that we will support, and this is why we are supporting one or two or twenty. This is how they will show up on the user's webpages. This is how users will choose on
(oops--hit the character limit. here's the rest of the comment I just posted)
This is how users will choose one over the other, and here's why we are going in this direction. And so on.
Publish this on a webpage, permalinked, and pointed to from the Blogger page or somewhere accessible. After that, I think it will be easier to discuss these things based on actual information rather than speculation.
I'm sure Blogger can do this, and I'd rather think that if they haven't done it already it's not because of some weird dark purpose but a more simple reason, (a simple oversight will do). But since the discussion has started, now would be a good time to clear things up.
Maybe I'm wrong, but from where I stand this doesn't look hard to do. This information has little if any competitive value and it will be out anyway as soon as they release, which seems to be pretty soon.
Of course, if Blogger has some reason for not doing it, and they don't want to explain even thos
(cut off again -- here's the last paragraph)
Of course, if Blogger has some reason for not doing it, and they don't want to explain even those reasons to users and others in a community, that sort of complicates things.
Diego: good point. All I really wanted to do was start a conversation. Evan isn't being very transparent in what he's doing and why he's doing it.
It makes it hard over here on the Microsoft side of the fence to figure out what to do so we're compatible with (and friendly toward) Google.
Diego, I'd love to see it clarified by Blogger, and further, I'd love to see the spec they're implementing, so I can get ready to support it in Channel Z (one of its features will be the ability to publish to blogging tools like Blogger, Radio, Manila, MT, etc).
But, Scoble asked about more than that, he wants to know what the selling proposition is for Atom. In the larger world new formats must somehow explain why they exist. RSS was simple, the existing methods for syndication at the time (mainly ICE) were hugely complicated and favored large vendors like Vignette and a few others. We wanted a format that could be implemented easily by small developers quickly. Now, what's the equivalent rationale for Atom, given that it's 2003 and RSS (with all its flaws, hat-tip to Mark) exists and is deployed widely.
In a way Scoble (and I) are trying to help the Atom cause, by asking the questions *everyone* but Blogger will ask (and the management at Google should axe). We suppose th
(continued)
We suppose that Blogger, if they were being honest would say "We don't like Dave." But I doubt if Google management cares, if they really knew.
You can say that again. 
"actually I think I know -- your case for Atom is so weak you have to mislead people about RSS."
You know Dave, everytime you make one of those statements it gets harder for those of us who'd like to support you to continue respecting you.
And M$FT already has an RSS equivalent. It's called CDF
I've followed the Atom vs RSS discussion on and off for a few months now and it's very frustrating. Lots of heat has been generated, but no light.
Can somebody answer Scoble's question: Why Atom? Where is RSS weak?
What about Mark's claim that there are 7 partially compatible versions of the RSS spec out there; that semantics for some elements differ between versions? Is he correct? Is Dave glossing over a problem when he says you could relabel an RSS feed with a newer version and it will still validate?
Why is this issue presented as an either / or proposition? It seems to me that if an application supports 7 versions of RSS, what's the big deal about adding support for Atom?
Anon, oh really?
Actually that was the kind of reasoning my mother taught me, and she was right. When people spend a lot of time trying to change the subject to talk about your flaws, it's likely they're doing it because they don't want you to notice theirs.
Anyway, I'm far past the point where I worry about displeasing most people, and I certainly don't worry about displeasing people who won't even say who they are.
Try again.
Cory, no Dave is not glossing over a problem -- Mark is trying to create one. Most people who implement RSS don't care whether there are 7 or 2 different versions. They just find a feed they like and do what it does. Kind of like the way HTML works.
Mark is a brilliant technologist who studies specs, and maybe someday will write them too. He finds problems, and for that he does a good thing. But he adds some awful judgement to the mix, which is not good. Sure, I make mistakes, but if you never step up to the plate you can't strike out. The problem I've had with Mark is that he condemns me for making mistakes, instead of working with me to help people work around them.
When Atom finally comes out, btw, it will have mistakes too.
Dave: The current draft specification for the Atom syndication format is version 0.2 and is available here. The current draft specification for the Atom API is version 0.7 is available here. Both of these specifications have been publicly available from the Atom wiki. If via the wiki, the Atom syntax mailing list, email, phone or whatever, I'm happy (as others hopefully are) to work toward a common goal of support for Atom in tools like Channel Z.
Now, imagine a new syndication format that brought up a page that showed what a news aggregator was, and explained how the system worked and why it's more productive.
Neither Atom nor RSS can do that.
I don't think that's going to remain the case. There have been many discussions on the Atom wiki about how the XML icons which yield browser gibberish are not nearly good enough a user experience, and I would expect that a solution to that problem will evolve through the Atom process, probably something very similar to what you've described.
Anil, the white on orange XML buttons worked fantastically. At the time they came out, people were hearing huge hype about XML but most people had never seen it. At least at that point they knew that it was what you call "gibberish." A fair number of people looked at it and saw that it wasn't that complicated or hard to understand.
As usual, you don't show enough respect for the difficult problems that were solved before you took an interest. My experience is that successful technologists learn from the process of invention, and don't dismiss things just because they didn't think of them.
A lot of your initial bluster about Atom has failed to materialize. Where is the open process? What have you accomplished in the five months you've been working on this? So far it looks like you've just reinvented what already exists.
David, does everyone agree that those are the final specs? (I would guess not since they have version numbers that say otherwise.) How could Blogger be implementing Atom if the spec isn't final? Is it safe to build apps on that or will they break? What's the roadmap? How are decisions made in the Atom process?
Scoble (re. Longhorn integration): I would be very supprised if smart programmers at Microsoft couldn't do the ingration you envissioned. Yes you do have to look at the first 2 token groups in the data content to detect a RSS2 format but Microsoft programmers have gotten very good at this kind of expection
programming.
(NOTE: Long post - split into parts 1/3)
(I see the question Scoble asked as what should MS do now that Blogger supports Atom API?)
OK I look at a Weblog as (at least) 3 parts:
- the warehouse/manufacture
- the presenter
- the consumer (today mostly a PC aggregator)
The consumer of tomorrow will change.
People are already talking about cell phone useage and bots.
The desktop aggregator will be expected to recognize syndication format and deal with it, be it RSS .92, RSS 2.1, Atom or the MS-MAN (MuchAboutNothing) format.
It WOULD have been much easier to just deal with a single format (see Dave's www.scripting.com for reasons) but even with RSS 2.0 people seem to be having problems producing a single feed as they will have several XML buttons for: with/without enclosures, full/condensed article, comment/trackback integration.
I can't see people taking a full, with enclosures and comments to a SMS (Smart) phone. Even without the message cost the bandwidth just isn't there
(NOTE: Long post - split into parts 2/3)
OK I look at a Weblog as (at least) 3 parts:
- the warehouse/manufacture
- the presenter
- the consumer (today mostly a PC aggregator)
The presenter is that piece of logic/code just behind orange XML (or blue? Atom) button. Most of that piece today is static or simple minded in order to lower overhead but the format used by aggregators is just a different report format and can be done for multiple formats. (Something like doing multiple saveAs and selecting different types each time.) A smart presenter (such as what Dave(Manila) or Mark(MoveableType) use) can create the requested report dynamically. Note that overhead is reduced by caching frequent requests, even pre-populating the cache with some of the latest feed reports. Blogger (mostly a warehouse/manufacturer) opts for
only creating a single (feed)report (due to overhead) but could produce RSS 2.0, Atom (and even MS-MAN) from a checkbox interface. The Atom format with its REST inte
(part 2 cont)
The Atom format with its REST interface make it easy to select different types of report formats (month at a glance) but as I understand there is no technical reason that www.scripting.com/rss.xml?enclosure=no&
comments=yes could not be implemented
(or even archive.scripting.com/2003/11/rss.xml?
enclosure=yes&comments=yes for those with a T3).
(3/3)The warehouse/manufacture is where I think the biggest opportunity exists for Longhorn. Imagine a Weblog creation system setting on top of the Longhorn file system with its builtin multiple indexes (or whatever it is) and a defined MS-MAN interface to allow remote access. Although I think the single AtomAPI interface may be easier to deal with then the Blogger/MetaWeblog APIs a MS-SOAP interface to a MS-MAN api MAY be necessary. The maintainence of 3edParty aggregator "producer" fuctions (posting to weblog based on article) will get overwhelming if they all have to support each API. I think that successful warehouse/manufactures will support (at some level) multiple APIs.
(last)Do you think that people would not add in the already available Blogger/MetaWeblog api to MoveableType if SixApart decided to only ship the Atom api? If Userland limits support you can bet that myelin will have the Atom api soon.
Now if MicroSoft could just layout a direction and start supplying the construction materials for the warehouse/manufactures in 2004....
The selling proposition for Atom I believe is more technically motivated (providing a unified syndication format *and* editing API) at this point with the end goal of providing a richer user experience (via tools). To put words into the Blogger folks' mouths, they supported Atom because they wanted to work on a vendor neutral format *and* editing API given that they were abandoning the Blogger 2 API. Evan talks about their motivation in this entry.
I point to the motivation page from the Atom wiki for other motivations. Some of those end user benefits are mentioned in one of the questions. Our experience will eventually (and already has in some instances - case and point, RSS enclosures) go beyond needing to retrieve and process information from text. To take a
(cont). To take a quote from Dave Winer from Roadmap portion of the RSS 2.0 specification, "We anticipate possible 2.0.2 or 2.0.3 versions, etc. only for the purpose of clarifying the specification, not for adding new features to the format. Subsequent work should happen in modules, using namespaces, and in completely new syndication formats, with new names." It just happens in this case that folks developed a new syndication format with a new name.
Speaking of user experience, just a note to keep an eye open for the first evaluation release of iMunch, an integrated aggregator, editor, blog administrator and tabbed browser built on our Zeepe framework.
One of the nice things iMunch does is to sense when you are browsing someplace that has a valid RSS feed and offers to add it to your diet. Say yes, and it gets added to your Muncher in the category of your choice. Simple as that. Good for Granny, yes?
Anyone skilled in (D)HTML will be encouraged to dig in and tweak/enhance/break their copy, too.
Coming Real Soon Now
Sure. The biggest advantage Atom has over RSS is that the syndication portion of Atom is (in theory) completely congruent with the API portion of Atom. You won't ever get elements that are valid in syndication but which can't be set via the API. That's fairly significant, in my book.
Dave: To answer your questions. 1) No, I don't believe those specifications will be the final specifications. 2) Blogger has developed support for providing an Atom syndication feed. I do not know what they have done with Blogger regarding support for the Atom API. They are seeing what works and how easy it is to build support for the current specification in their tool. We have done this with blojsom which provides a template for Atom syndication and a component for interaction via the Atom API. We did this around a toolkit aptly named, Sandler 3) Yes, Sandler may break when the Atom API 0.8 specification comes available. However, we want to see adoption of the format and API. So, when it is released we will update Sandler and consequently, blojsom. The same thing will happen for Ben Trott's XML::Atom library.
So forgive me for taking the "fix it now" approach. But what about putting a link next to the nifty orange + white XML & RSS buttons that says "What's this?" and pops up an explanation or having an explanation contained in the text?
I've got something like this on my homepage. It's pretty simple, but I think it'll do. I'm expecting Microsoft to buy me out any day now for this idea.
Dave said: Most people who implement RSS don't care whether there are 7 or 2 different versions. They just find a feed they like and do what it does. Kind of like the way HTML works.
Doesn't that logic easily extend to Atom?
And Bryant- thanks for the explanation. This issue is starting to make some sense to me. Don's post expresses exactly what I was thinking after I read your explanation.
(cont) 4) The roadmap will now evolve from discussions on the mailing list and the wiki and individual blogs. There are also bloggers out there who are trying to maintain a high level snapshot of current discussions and happenings regarding Atom. See the Finally Echo blog. So, we need to do a good job at collecting those voices speaking up about Atom and update the Wiki and mailing list as appropriate. The same thing has to be done for other formats like RSS. You've done something similar with your analysis of issues page for RSS. 5) Decisions will be made (hopefully) by the Atom and weblog community's input. Anyone has the right to blog about Atom and its shortcomings and its advantages (as with RSS). Anyone has the right to sign up for the Atom mailing list and participate in that discussion. As with RSS, choosing whether or not to or how much to participat
(cont) As with RSS, choosing whether or not to or how much to participate is still up to the individual. However, the venues are there for you to make your points known.
"the venues are there for you to make your points known."
I disagree David. People make their points known on the Wiki yet the Atom 'specs' keep rolling over them.
Bryan, RSS has the same relationship with the MetaWeblog API. In fact, it's reasonable to assume that's where they got the idea that it's possible.
The fact that he put an Atom feed up on his own weblog is a major hint to the marketplace that Google is going in the Atom direction.
I don't think so. It's a hint that Evan is experimenting with it. It's a hint that "Google" (!= "Evan") is *possibly* evaluating it and considering the idea of going in that direction.
I'll take back the "FUD" comment. I think you're just reading too much into it.
Robert, as it has largely been my project to coordinate Blogger's Atom support and not Evan's I thought I would take a crack at your questions.
As I posted on my blog recently, the feeds that we released are beta example feeds though we intend to produce Atom feeds for all Blogger users soon. This should be fairly transparent since we first voiced suupport for the Atom process back in June and have been active participants in this process since then.
(cont)
As far as a detailed analysis of the benefits of Atom syndication and why the AtomAPI is a good way to go, view the initial motivations for starters.
Mark, didn't you and Sam spend some time with Evan's team sometime ago to discuss Atom in context of Blogger? Could you shed some light on what their plan is without violating NDA?
Don, my favorite moment was when a vote was taken on whether Atom should use XML-RPC or not, and when the consensus was that it should, Sam decided that the question was asked incorrectly, or it was too early or something like that. Then they had a big discussion, and all our votes were inverted. People who supported XML-RPC were "refactored" to be against it. At that point I stopped watching the Wiki, figuring that whatever Sam and Ken MacLeod wanted would be what the community ended up wanting.
Oops. Now that Jason is here, I guess we can hear directly. Hi Jason!
Don: To clarify, you take issue with the fact that when someone makes a point on the Wiki it is not reflected in the specification and *not* that the venue isn't there. I cannot point to specific instances of that happening myself, but I am also guilty of following the specifications when released and not the discussions of how those specifications came to be. You make an excellent point that going forward some reasonable effort should be made to provide justification for reasons why, for example, points collected from various venues that Points 1, 2, and 3 were addressed, Points 4, 5, and 6 will be addressed later, and points 7, 8, and 9 will not be addressed.
(cont) As an aside, I think the assertions about launching an industry-wide process based on personality conflicts should be set aside. The list of supporters of this process includes many reputable folks who want to advance blogging and the technology herein. Furthermore, there is an well intended alliance of companies and developers who are actually coding to the specs that have been written and implementing them in existing products. Atom is alive and well and perhaps just in need of some breathing room in the face of ready critics.
Paul,
"I don't think so. It's a hint that Evan is experimenting with it. It's a hint that "Google" (!= "Evan") is *possibly* evaluating it and considering the idea of going in that direction."
Not really. Evan clearly says in the post that the feed is *generated by Blogger*, not by "handcoded" by him. This clearly implies that the code is already into Blogger that outputs Atom, and that goes beyond anyone's definition of "[Google] *possibly* evaluating it". Yes, it could theoretically not be released, but that's a different matter.
Dave,
Whether Atom adopts RSS 2.0 or not, I think the Atom 'process' needs to be redesigned. I would like to see the process of module creation formalized, streamlined, and timelined so we can keep adding to the momentum without going around in circles.
"As an aside, I think the assertions about launching an industry-wide process based on personality conflicts should be set aside."
Ouch! Point taken and my assertions withdrawn.
Jason, I think that what isn't clear, and what is generating the discussion, is whether Blogger is leaving RSS completely for Atom or not, if so why, and if not why not, and how exactly will this happen (as far as user experience is concerned). Most of us, I think, were aware of Blogger's involvement in Atom, the goals stated in the Wiki, etc. I think that this is what Dave refers to as "the selling proposition".
This is important in itself, but also for those of us that develop aggregators (even if they already support Atom, like mine does) this knowledge helps in documentation, testing, etc.
Huh. Dave is absolutely right; I stand corrected. The metaWeblog API includes that feature as well.
However, I do not think it likely that Atom got that idea from the metaWeblog API. The API spec archived on 8/8/2003 (http://www.xmlrpc.com/stories/storyReader$2509) does not specify this behavior. The current API spec does.
Atom launched well before 8/8/2003. As of the 7/7/2003 version of the roadmap (the earliest one available on the wiki), there's clear intent to build both a syndication format, an archiving format, and an editing protocol using the Atom spec.
It may have been Dave's intent that elements in namespaces be passed as sub-structs, but I wouldn't assume that the Atom folks derived the idea from Dave. Nor would I assume that Dave derived the idea from them.
Bryant, that feature of the MetaWeblog API goes back to March 2002 way before there was any talk of Atom.
Jason, not sure if I'm a "ready critic" or not -- but who cares. Where's the spec you're implementing and how was it arrived at?
Um, Jason, your feed doesn't work in NewsGator. Neither does Evan's. Why again do developers need to do more work to support multiple formats that really don't have many extra features?
Look at it the other way. If Microsoft was doing ATOM, would you like it or complain?
Form follows function.
As such, the would-be standard that derives from "white sheeting" has, beyond generalities, only accidental relevance to companies who want a standard that satisfies their strategic particulars. To wit: Robert wants integration with Longhorn.
Google is a search/ad placement company.
So Google wants a standard that enables blogspace to be more precisely searchable/easily navigable.
Here RDF trumps XML, so Atom2RDF (which is lossless, will happen (maybe purely under the hood).
The rest of the story is in my above comments...
For gleaning the longer-term implications of Blogger's support for Atom, the rest of the above commentary is meaningless. White sheeters don't design their specs to advance a given company's strategy, and the above comments make plain that they have no interest in a thought exercise wherein they hypothesize the motivations of Google executives...
Robert, I fully expect Microsoft to "Embrace and extend" RSS. They've (You've?) already tried to create a content delivery system (CDF) and failed (in terms of acceptance technically CDF seemed fine). I think at that point we'll have the same schism we have now. We'll have news feeds based on MS-RSS that work well with Microsofts news readers and we'll have the rest of the worlds news feeds that Microsofts readers won't quite read as well.
As a developer this concerns me because I'll have to support both markets. Whenever a company deviates from a standard the developer has a decision to make. Alienate a section of their users or work harder to include everyone.
Scott, too true. And eventually you'll need a multi-billion-dollar R&D budget to create an aggregator or blogging tool.
I'm still trying to care about aggregator formats. No, really, if it's not available in an aggregator then view it with one of those old fashioned browser things, and if that doesn't work you probably won't be able to read it with anything, so go off and do something productive with your day.
Geez....
Remember Arcterx, in Roberts world the web is dead. Microsoft, or some faction within Microsoft, killed it off with Longhorn. We won't be able to use a browser to view the thousands of RSS feeds we'll read each day. We'll have to open up our Longhorn news reader which comes standard with our Longhorn operating system on our Longhorn DRM based BIOS powered computer in our Longhorn chair under a Longhorn sky in a Longhorn world.
...and thousands of Kansas State, Nebraska, and Oklahoma alumni will switch to Linux.
Scott: guess what? Mozilla still works in Longhorn. The black helicopters will have to come for you another day.
Speaking as an aggregator developer, I HATE the fact that there are already multiple different syndication formats. Not because it's difficult to support them, because honestly, it's pretty trivial. I hate it because the different formats confuse my users. And that's the most important thing to me.
Syndication and aggregation are already difficult concepts to explain to non-techies. Then you throw in the multitude of formats, and they don't know what to subscribe to, making it all the more difficult.
In this light, I cannot see how Atom will improve the situation.
Robert - Atom feeds work in NewsGator 1.3.0.9. What version are you running?
Regarding the spec, we are implementing the specs available via the Atom wiki and have made changes in accordance with discussions on the syntax list. Since this is a moving target, the 0.3 syndication and 0.8 API spec aren't firm, they are subject to minor changes.
Jason, so if the spec changes you'll change? Or do you consider it fully baked now?
Robert, could I ask you to think about looking into a different commenting mechanism that allows for longer comments? Following this discussion with all of these comments broken out over 2 or 3 comments is really challenging for anyone but the most hardcore blog readers. I think you need more functionality than Haloscan provides.
Gen, I'm evaluating commenting options. Do you have any I should consider?
Jason, I'm using a version of Newsgator that is not publicly available yet. I'll report that as a bug to Greg.
Sorry, I had to post #100.
I think it comes down to the simple fact that Open Source wants control of every standard, and then implementation. I call this irony, but you can call it whatever you like.
The part that I find interesting is that Evan (or whoever is responsible) is hiding behind Google. I don’t recall Dave Winer asking for shelter from Microsoft to play games. Maybe you shouldn’t either Evan, and how about answering the question that was presented. In an effort to find benefits of Atom, we are still standing at zero.
I looked at the David’s link on “why Atom,” and my main takeaway was that they wanted control. They say for the better, but why can’t RSS do that. Dave says he plans to stop at 2.0, but that is probably because he can’t envision what 2.1 or 3.0 even looks like.
Wow, you sure know how to throw a party, Scoble.
Frankly, I am compelled to point out that all lowercase names are esthetically more appealing than camelcase names and this aspect of Atom feed format has some design value. Meanwhile, I am still looking.
Robert, you can use my Manila server. It's a 3Ghz box, and hardly carrying any load at all. It'd be very fast and wouldn't have this limit.
Ryan, whether or not I can envision something beyond 2.0 is irrelevant. People miss the point TOTALLY when they think something different could happen if only I'd cooperate, so much so that they haven't incorporated the fact that I've fully relinquished control into their model of the world. If only Dave would.. gets you nowhere. There's nothing to do. Perhaps if Blogger and Movable Type would support RSS 2.0 in the spirit of RSS, then something new could happen in this space. But they've been very grudging in their support, to put it mildly. It's almost as if they resent RSS's success. Of course RSS is just a spec. Personally I thing Blogger should be more worried about giving their users features they want, rather than making it more complicated for them. But that's harder work than ripping everything up and starting over. End of ramble, it's been a long, but interesting day.
Dave, we're trying to get get Robert to switch blogging software, the load isn't the problem, it's the free haloscan commenting system which is only worth it if you don't have as many geek friends/fans as Robert.
I think it is incredible that this conversation is happening on a blog that doesn't even register comments in my aggregator...
Dave, I'd love to switch back to Radio comments. I'll talk with you offline about that.
Shannon, I know the load isn't the problem with Haloscan, I anticipated that Robert might have a concern with the load on the Manila server, since he switched from Manila to Haloscan. UserLand's comment server is hugely overloaded. Mine is hugely *not*.
BTW, you'll be able to subscribe to his comments.
Robert:
Do you remember why you switched from Radio Userland comments system in the first place?
I think whatever problem was there that caused you to switch is still there. Many days the system seems to fail sporadically causing javascript errors in downloaded weblog pages ( the traceback system is about the same).
If this is the same system Dave is talking about switching back to I would think again. If not then why is Dave offering a "better" system here than his other customers get?
The utility of both comments systems though (Haloscan and RU) though is somewhat suspect. A few comments on a post seem to be fine but when the number starts to increase with no threading and poor display the comments get unmanageable IMHO.
I also find that RadioComments server has reliability problems. While some of that seems to stem from excessive load, I think there are other problems that causes the server to go down few times a day.
Aside from this, blog comment is a gold mine for improvements in the near future.
Am I the only one that is chuckling at the fact that people are discussing Microsoft potentially installing a new syndication format on every Windows PC in the world... on a site that has insightful authors being forced to split their work into multiple pieces to get around limitations of the blogging software?
Dave, I think you can subscribe to his comments here, too. I seem to remember doing it once, it was horrible. In a good (or maybe I should just say "better") blogging system, there is a field for the number of comments a post has (maybe "commentAPI" something? I haven't really bothered learning, it just works) and you can click the link and it will open the Post AND the comments on the same page. Amazing, simple, and simply amazing that anyone would do it any other way...
Yeah, the comments syndication sucked. I subscribed to them for a short time when the option was available here. All I received was the comment itself with no context, comments attached to a post weren't even threaded together (using SharpReader, maybe other aggregators can auto-thread the comments?).
Chris Sells feed has the comments attached to the parent post. Nice.
Atom-Syntax Sin Tax
JustSayNoToAtomFeed
I don't think what Microsoft are likely to do has much significance on whether or not there's a need for Atom.
If you try doing anything beyond simple display with RSS 2.0, its limitations quickly become apparent. RSS 1.0 is a lot more sophisticated, and its adoption is roughly the same as RSS 2.0.
Both formats are getting on in years (as Dave says, RSS 2.0 is largely the same as 0.91), but the environment's changed.
Microsoft have moved on from DOS, the syndication world needs to move on too.
Danny: that's a funny opinion to have because so few people are using syndication. So, what's the feature you need?
If Microsoft wants to roll up its sleeves why doesn't it provide a place not a plan. Do you have to design a species? Construct an environment and any species will redesign itself. Regardless of the syndication format we need a place to discuss our ideas lucidly. As evidence I submit this 100 something post.
I haven't been tracking Atom closely recently, but the *technical* advantages were:
1. It's in a namespace, so you can ship it around in for example a SOAP package, without breaking anything.
2. It handles xml:base so you can have relative URIs in your feed and things will work.
3. It has a clean declaration of whether the content is real XML or escaped XML or base64, so you don't get the really evil interpreted-escaped and even interpreted-double-escaped stuff that I see in RSS
Tim, I would argue that the amount of effort required to solve those problems by extending RSS 2.0 is far less than the Atom feed approach and will definitely cause less confusion.
Has anybody proposed Tim Bray's technical advantages to the BOD of RSS 2.0?? (That would be Dave Winer, Jon Udell, and Brent Simmons last I heard from post and article in InfoWorld this past summer).
IS there an on-going RSS 2.0 forum someplace?? Who moderates it?? Imo, all this is not something that is best handled by Googling all of Blogaria to see what's what, as "mal" pointed out above.
(Even if the answer to all the above is no, Atom is still FUD intended to squash RSS, not make a better user-experience.)
Btw, but why does it take over a hundred posts for someone like Tim Bray to actually answer Scoble's original question with some specifics??
Also, I haven't seen the answer to Dave Winer's question as to whether these specs have been finalized and, if so, I would add that I'd like to know by whom and what does it mean "finalized"??
Where IS the purported spec going in the future??
What I gather is that, in essence, Google is gonna finalize them... "Because they can".. "No guts no glory".. "yada, yada, etc."
Don: I don't see how you could have compatibility with RSS 2, technically. RSS 2 elements are not in a namespace, in fact explicitly specified not to be in a namespace.
Last time I checked, the RSS2 roadmap said clearly that these kinds of changes are not on for RSS 2.0, if you want to make fundamental changes you should give your format a new name.
On the other hand maybe I'm missing something.
Tim, right, if you're going to produce something that's not compatible with RSS, give it a new name. That's what the roadmap says. But why give everything a new name just to fix a few things? I can see some value in being able to ship around a weblog item in a SOAP package. (Maybe.) It seems like giving everything a new name was the objective of Atom, not fixing a few problems. I also find it really weird that XML-RPC isn't one of the supported protocols, when that's the only protocol that all the blogging tools use today.
Dave, because fixing things required breaking compatibility with feed-consuming software, even if technically the specs were still compatible.
So, if you're going to have to break backward compatibility to make fixes to the spec, why not go whole hog?
Mr. Bray,
Technicality solved: RSD 3.0 = Really Simple Data. Propose new name and such to RSS 2.0 BOD, and see if the crap sinks or floats. Either way, anybody else (in addition to or, imv preferably, besides the Atom mob) can ALSO try a similar approach, according to what I've read about RSS2 license.
Redesigning everything from scratch and dumping everything that's currently in use has a lotta appeal to it, but will (imo) fall flat on it's face when the reality is that the user-experience stays essentially unchanged. I'm not interested in promises of a grand user-experience just a few years down the road (a la Longhorn and such, any more than RDF/Atom), nor are most users.
Adam Rice, from bottom of (http://intertwingly.net/wiki/pie/
JustSayNoToAtomFeed):
"RSS2 is good; Atom, as currently specified, will be better." Yeah, yeah, yeah... I've always heard that line once too often (..like MANY times too often): "What WILL be is gonna be SO much better than wha
Jes LOVE this comment system... At least only lost a part of it.
Can probably see where I was going in last paragraph above.
Point is: 2 or 3 years down the road the advances that actually HAVE taken place makes SO much-a the current discussion about redesigning from scratch is obsolete before any-a it ever hits the product line. And academic exercises and give-away-for-free markets are NOT equivalent to selling products, though the freebies will tend to have more consumers (but no customers).
I'll guarantee I'm missing a few things, like, I don't recall all the discussion of why RSS2 elements weren't put in their own namespace (breakage?). Point is, I agree with the RDF/Atom folks on this ONE point, at least:
That was then. Question is, what is it now?
Mr. Bernstein,
"So, if you're going to have to break backward compatibility to make fixes to the spec, why not go whole hog?"
This is a very sad joke on the readers of the NY Times who currently use RSS. Imv, a sick joke on the developers of aggregators, too... Yeah, promise them anything, and make the delivery date far enough down the road that they'll forget who promised what.
Btw, who DOES own the Atom spec?
Tim,
What is wrong with introducing a namespaced element to be used as an envelop for embedding purpose? If namespace-less elements are like water, all you need is a bag.
JayT you can be my rabbi. Where do I sign up?
Don: I don't think that helps much. The whole idea is that if you're in a multi-tagset environment, the way to play nice is to be in a namespace. RSS doesn't. Now it's possible to work around this, by saying that "everything that's not in any namespace is assumed to be RSS" and hope that nobody else isn't playing nice, or "anything that's inside this special wrapper is assumed to be RSS", but the point is that lots of new XML code is built to assume that it can dispatch on namespaces and so this special code is going to be extra work.
I note that SOAP 1.2 says message bodies SHOULD (not MUST) be namespaced (if I'm reading sect5.3 correctly) but as of now, the cost of not having a namespace is that RSS is more work to handle than other XML vocabularies. I've never said this will cause the world to end, just cause more work for developers.
JayT: I can recall high-volume multi-way email exchanges between myself and Dave and Ziv Caspi and others back in September 20
heh... JayT: There were heavy email exchanges in 2002 over RSS2 and namespaces, I failed to convince Dave that it was a good idea, I seem to recall him writing a summary of why he decided against it but I don't have a pointer.
Does anyone seriously think that any Atom participants beleive RSS is going to just go away? Breaking backward compatibility with RSS does not mean that all existing RSS feeds magically stop working in aggregators.
The NY Times can go on providing RSS feeds till the cows come home, and all newsreaders will probably continue to support it as a basic data-delivery format. But the RSS format is now getting in the way for many proposed uses, and we need a better way forward than workarounds piled on more workarounds.
Will Atom be perfect? No. I'm sure that after a while it will also reveal flaws, but at least an attempt is being made to shake out as many of them as possible and as early as possible, and to learn from the mistakes made with RSS, so we can continue to move forward while putting off the inevitable necessity of replacing Atom with something else as long as we can.
That is why the Atom specification process is taking so long, we're trying, as best as we can, to take
(cont.)
That is why the Atom specification process is taking so long, we're trying, as best as we can, to take the time to make the correct trade-offs.
That decision in itself is a trade-off, and one that is very different from the decisions Dave made with RSS, which was to ship working software to users as soon as possible, and live with the bugs in the spec, because you can never get rid of all of them, and many of them can be fixed later.
Both are very valid approaches. I for one am happy to let the two formats compete on their merits in the marketplace. RSS has a first-mover advantage, and a large established base. I still think Atom can succeed by allowing developers to easily deliver a better (and more differentiated) end-user experience.
That's a REAL nice compliment Dave! But I don't joke about those kinds-a things. I'm no Rabbi and even if you mean lower-case-rabbi..
Well..
..you've (I'm sure unintentionally) put me in an awkward position because YOU'RE one-a my MAIN rabbis. I have several hundred/thousand teachers, but you're one-a the biggies... So, you see the awkwardness of my position, I hope. (Among other things.)
Mr. Bray, thank you for confirming EXACTLY what I said above: "I can guarantee I'm missing a few things." The conversations I was recollecting were about a year ago last spring, iirc. And I think I recall the name Ziv Caspi from about a month back, but I can't quite picture a "voice". (Sorry, but "memory is good, just short".)
So was that exchange fruitful at all? And were all the man-years that have ALREADY been put into Atom mainly (speaking wrt technology ONLY) a result of RSS2 not being in it's own namespace?!? (And there is how big-a corner turn to correct?)
Tim, use a search engine to refresh your memory. It wasn't aesthetics, it was about breakage and the installed base, I did propose a very good solution, but no one was interested in solutions, they mostly want to jump up and down and proclaim themselves king of the hill, kind of like what Michael Bernstein is doing in this thread. His reconstruction of RSS history is a nice story, doesn't happen to contain one grain of truth. Seeya later.
Tim, I don't know about you but I have seen very little XML software that 'dispatch on namespaces' per element.
What I have seen are designs that follow the 'Atoms and Molecules' design pattern in that a document is composed of chunks (aka molecule) made up of simple elements (aka atom) or smaller chunks.
So code uses the namespace to 'dispatch on namespaces' per chunks which fits very well with envelope and payload approach for embedding RSS.
Aside from this discussion, I love streaming XML parser APIs like StAX because it makes it easy to apply the Atoms and Molecules design pattern.
What reconstruction (and, pedant that I am, I think you actually meant revision)? You said, at various points, both publicly and privately, that sometimes you can't wait to get it perfect anymore, that you need to ship real software to real users. That is a paraphrase from memory, yes, but I think it accurately represents what you said. I can dig up an actual quote if you prefer.
Anyway, I don't actually disagree with you in principle, but many people (including me) complained that you cut off discussion too soon on various issues, deployed your software, and then refused to reopen the discussion if it meant that any already deployed software would break.
We all understand that Userland is a business, and needed to ship software to survive, but if that means that you make a decision in haste, you also need to be able to revisit those decisions and fix it later. If you can't revisit those decisions, then if needs must, you fix the mistake in a new format.
Well, Atom is a new
Well, Atom is a new format. It takes both inspiration (XML content syndication over HTTP) and hard won lessons (namespaces, strictness of the spec)from RSS, and nothing more. Why would a new format that breaks backward compatibility need to preserve element names? The element names are just the most superficial portion of the spec.
Oh, and one more point: Keeping the element names might actually create a false expectation of compatibility where none exists, harming the marketplace much more.
It has been really refreshing to read all of this when I really don't have more than a rudimentary understanding of the technical specifics being discussed. What I keep thinking is that RSS, as is, allows me to cover a lot of information in a somewhat painless way and you guys are going to fuck it up for awhile which will be another pain in the ass.
I've been a user since dos 2 and for years was like a moth to the flame of newer, bigger, better. Now I stop using things that piss me off over and over and counsel my clients to use a conservative approach and avoid conversations with people who say things like a rich user experience or ROI or TCO. I'm not alone, there are a lot of us in NY who have been dragged around the block too many times. If you want to do something new go ahead and do it. If it can drag business away from what exists it will, otherwise it will edsel. If you setup competing standards you'll fragment the market and it will be wordperfect vs word, or mac vs pc a
all over again. One of the big boys will stretch their market share a new generation of aol will be born and the net will lose but one more piece of what gives it so much potential, communication to anyone who signs on.
There probably isn't any way to understand exactly how many are currently using news aggregators but I assume from the constant proliferation of new feeds that seem to pop up over night, both amateur and professional, that there must be a consumer or two out here somewhere. Whoever authors the standards will do just that. If Google or anyone else pulls a power play with one standard, as Microsft has in the past, there will be some more pissing contests. The developer that comes up with the aggregator that can read the most syndication standards will make some fast money until others catch up. Most non-techies who use this stuff read the summaries and go to the websites to read the full articles of what interests them. If the purpose of all this posturing is to evolv
evolve something that can carry a ton of content then you turning it into something else entirely and should write something new (based on the current concept), call it something different, and don't fuckup what is working and catching on today. Otherwise you'll piss people off and they'll either stop using it or won't upgrade to anything different.
I know quite a few lawyers that are still convinced that 386 machines running DOS and Wordperfect would save them a lot of money and help them practice more law. I don't agree with them but their point is well taken. The novelty of individuals being able to compute is wearing off and entering into the era of "I need one to get stuff done."
Robert - I can get you setup on your own server (the penguin) on your own site and I'll even load and configure MovableType for you. Then you could get on to your business objectives on a solid platform.
I really don't understand why MS hasn't set you up yet, I'm sure Google would...
Scott: "I fully expect Microsoft to 'Embrace and extend' RSS."
Of course there is a version of RSS that was designed to accept extending without succumbing to the MSFT "embrace and extend" philosophy, RSS 1.0. Been around and in use for a few years now. Works pretty well.
Scoble: "Look at it the other way. If Microsoft was doing ATOM, would you like it or complain?"
If MSFT was designing Atom in the same design by fiat unilateral manner that the various UserlandRSS have been designed, and then using its traditional market tactics to cram it down everyone's throat of course we would complain. How is that relevant?
Also all this concern about the spec changing seems to be a red herring. Afterall the UserlandRSS specs used to change overnight, at whim, everytime Dave had a good idea.
Also I fail to understand how having Dave arbitrarily appoint 2 people and himself to control UserlandRSS is supposed to somehow make it an open standard.
Look, I'm a user. Plain and simple. I run Net News Wire on my Mac and follow about sixty sites a day: moderate-to-bad news addiction, but I'm not a pro.
Let me tell you: I don't give a shit about your standards. I'm depressed to see your pathetic internecine rivalries escalate to this degree, and I've got news for you all.
Bill Gates and Larry Elison have something worth fighting about. They have a vendetta worthy of the name.
You all are like squabbing children.
Where the hell is the user in your picture? Nowhere. Everybody's bitching about syntaxes, and data flows, and representation of non-english languages and multimedia and all the rest of it.
You know what? We have XSLT do to most of that for us, and if you can't write a wrapper function from one API to another, you don't deserve to be called a programmer.
Why the hell don't you just agree to disagree, and have somebody start a little shop specifically maintaining a library of tools which will both conv
(truncating bastard)
Why the hell don't you just agree to disagree, and have somebody start a little shop specifically maintaining a library of tools which will both convert a feed from one standard to another, and also provide an API wrapper, so I can make an XML-RPC/SOAP at CONVERT.COM, it'll reformat the request to the target system, and I'll get my data back: on the fly API conversion is really not that big a deal.
Happy?
Now stop squabbiling and write some tools. In case you hadn't noticed American democracy is falling, the TV is owned by the defense industry (or, worse, vise-versa) and the Trusted Computing Initiative is riding up high on the horse threatening to take away what remains of the Commons which DARPA accidentally created when they gave us the internet.
Refreshing democracy is going to require and educated, disciplined, literate populace, and a culture of open discussion, frank debate, and political relevance. And, by and large, we've got that in the B
(further truncation)
Refreshing democracy is going to require and educated, disciplined, literate populace, and a culture of open discussion, frank debate, and political relevance. And, by and large, we've got that in the Blogosphere.
Your standards, or lack of them, aren't going to change that significantly.
But if your energy is spent fighting eachother rather than writing code, we all lose.
You have the printing press. You can make free speech available to anybody in a way which it was not before, and co-create (with your users) an environment in which that which is important is widely read and debated, and that which is trivial is still available to those who want it.
Or, alternatively, you can refuse to print a goddamn thing until we all agree on which typeface to use.
Your call, gentlemen. Are you revolutionaries, or bickering children?
I'm really serious guys. If the Federalist papers had simply never been printed, because the press operators were too bus
I'm really serious guys. If the Federalist papers had simply never been printed, because the press operators were too busy arguing with eachother, where would we be?
--------------
Excuse the truncation. Sorry 'bout that chaps. I do mean this quite literally.
Ahh.... shit. Sorry about the tone of that folks...
I just came from watching a movie about Richard Nixon - the Redford one ("All the President's Men"?). The two Journalist-Heros spend the entire movie trying to convince their boss they have a story, trying to convince people to let them publish what they know. They don't have freedom of the press in a practical sense, and I do believe that similar journalists today would have a much, much rougher time in the newspapers.
But not online.
You all know, in your heart of hearts, that Bush II is a direct lineal descendent of Richard Nixon. It's the same black-ops, governmance-by-spying-autocracy bullshit that has been dominant in our culture since when? WW2? Korea? Vietnam?
Whenever you put the start of the rot, you know that the consolidation of power behind closed doors and disenfranchisement of the population has advanced to a deeply dangerous degree. Our politicans are incredibly accountable to large powerful companies,
(trunc)
Our politicans are incredibly accountable to large powerful companies, and incredibly unaccountable to the voter, and this is all wrong.
You can, individually and collectively, do something about that rot. Please don't spent your force fighting eachother, becoming demoralized, feelling like either you don't matter, or that you're being oppressed by the Powers that Be. You might, in the local sense, have some disagreements, but for god's sake...
Look at the world around you before you start rattling sabres at eachother. We actually need you to cooperate: not over standards or business, but as human beings .
Look at the wider context of your work. Think about us: the people who use your tools. We don't want you to fight eachother - just build whatever you're going to build, and we'll use what we like. Let us decide.
But don't drag eachother down, or we'll never get to the good stuff. And without it, how are we going to organize?
Michael, I hear you.
The main motivation behind Atom is to make it easier for developers to innovate. That's really what it's all about. Some of those developers will choose to focus on end-user facing features, functionality, and services. The easier we make building this software and making it all interoperate, the better, because more developers will be encouraged to play in this space.
A valid criticism is that developers now will have to support two data formats, which creates additional overhead. This is true, and unfortunate. But, it should be noted that despite RSS's deficiencies as a format (and the wildly varying quality of the actual feeds) it has been around long enough that there are now code libraries designed specifically to parse as many of the different feeds claiming to be RSS as possible. These libraries are in many cases even easy to use. Unfortunately, they have become encrusted with so much special-case code that moving forward and adding new features to
Unfortunately, they have become encrusted with so much special-case code that moving forward and adding new features to the blogosphere as a whole is now very difficult, so many developers are looking elsewhere for a clear path forward, and Atom is the result of their collaboration.
Splitting developer mindshare and effort between competing formats is unfortunate, but many people have seen it as unavoidable if we want to move forward in certain directions we find interesting.
Different people are interested in different things, but we all need more flexibility to extend syndication (on the one hand) to new domains, and standard support in the spec for things that have already been thought up, or that we already know we need to do (because people are doing them, albeit in non-standard ways).
Example of something simple we can't do today: Include Author information (such as a name) in a feed *without* an email address (important for keeping your email address from being harves
(cont.)
Example of something simple we can't do today: Include Author information (such as a name) in a feed *without* an email address (important for keeping your email address from being harvested by spammers). The options in this case are: leave off author info entirely, add an author email address (with or without a name), or use a fake email address along with the name.
Oh, I forgot one option: just put a name in the field, but no email address. Unfortunately, that last choice *does not* comply with the specification, which requires an email address as the field value.
There are other places where the spec leaves something to be desired, and none of it can be fixed. You can do workarounds (adding new elements in namespaces) for some of them, but it has been made very clear that you should not create new namespaced elements that overlap in functionality with existing elements in the spec. And even if your desired functionality is entirely new, putting it in a namespace is s
(cont.)
And even if your desired functionality is entirely new, putting it in a namespace is sub-optimal if the functionality is something that you're trying to create isn't something with only niche appeal (say something aimed at a vertical industry) but is something that you already know is going to be needed by a broad cross-section of users. Well, the list of things that we now know people will want to do with weblogs is quite a bit longer than when RSS was being devised, so we have an opportunity here in Atom to create 'official' new optional elements to standardize on this functionality and drive it's adoption (eg. no 'author' element but multiple 'contributor' elements on the feed, but single 'author' elements on entries for multi-author blogs (aside, other combinations of these elements can be used)), and also to retire elements that seemed a good idea at the time, but which nobody actually uses today (eg. textinput).
Enough developers were convinced of the need
(cont.)
Enough developers were convinced of the need to cut the gordian knot that RSS has become, that when they became aware of a credible effort to create a new format, they jumped on board in droves. While progress has not been swift (despite frequent storms of activity), Atom has been moving steadily towards it's goals. it *will* get there, and it *will* happen before pigs fly.
At the end, I beleive that the Atom format will make it easier to spread blogging and syndication to new developers, new markets, and new audiences.
Robert, you asked what features I was looking for. Tim points to some that would be on my list, another would be a well-defined extension mechanism (the key advantage RSS 1.0 has over RSS 2.0). The primary practical benefit would be true interoperability with other languages, so aggregators/blogging tools could become a lot more useful.
Other reasons why Atom is necessary are implicit in Michael's post. A new start is the only way a decent consensus can be achieved in the developer community. With Userland RSS it's always been Dave's way or not at all - hardly democratic (the move of the spec to Berkman doesn't appear to have changed anything in practice).
Regarding the end user, the limitations of RSS 2.0 make it harder to develop better applications. Unfortunately the RSS 2.0 thread is frozen, frozen with loads of faults.
Whether or not MS come out with their own format is orthogonal, Really Simple Syndication can only do so much, end users (like myself) expect more.
First, I incorporated all the ideas I could, that people offered. Lots of people wanted to argue about stuff that had nothing to do with the format. I couldn't put their ideas into the format. People who say I did it alone are telling an interesting story, but it isn't the way it happened.
Second, RSS 2.0 is definitely extensible. Lots of people have done it. I'd love to hear why people think it's not extensible.
[I changed my mind, and decided to post the stuff I wrote last night, with a few small edits.]
Mr. Kellan, I apologize for referring to you and Evan Williams as "nice young kids", earlier today.
Regardless of age, I would be curious if either of you, or anybody, has much comment on Mr. Diego Doval's post today? [And see, this morning, that Mr. Williams has made some comments there.] (http://www.dynamicobjects.com/d2r/archives/
002464.html#more). I didn't particpate in the process, other than scanning a few posts early on, and such, but noticed similar (from what I heard of a few of the goings-on, read, and then from studying the motivations behind the group in a little detail).
Btw, I posted similar question today, to an old post of Brent Simmons, but [probably] won't be able to check back and see if any reply. [Re: what the process is as far as RSS2 BOD.]
I think the relevance of Robert's question is that it appears Google will, in essence, be implementing a unilat
(cont.)
I think the relevance of Robert's question is that it appears Google will, in essence, be implementing a unilateral version of Atom (0.2 or 0.3?!? [or 0.8 or whatever])
I have some theoretical appreciation for a software house wanting to develop a competitive edge, and it may not wanna disclose ALL of what's planned. (The attempt to develop a better user-experience, whilst toeing the line to ANY given "standards" is too treacherous fer me.)
Here's the thing: The W3C approach to standards has been too slow (imv).
And I saw where the IETF put out an RFC on how they could improve their
process... So this whole biz of developing standards, code, product,
marketing and satisfied Customers (or consumers, if you give away the
product)..
..well, it's pretty tricky, as far as I can tell.
I'm guessing (or, I would suggest) that products will hafta
differentiate/innovate themselves in some way. (Not so much that they
HAFta, but that they will, in any event
(cont.)
I'm guessing (or, I would suggest) that products will hafta
differentiate/innovate themselves in some way. (Not so much that they
HAFta, but that they will, in any event.. oligopolies or not.) And a few ways would be in the areas of UI, support and reliabilty, and COT (cost of training, ie cost of anti-intuitive UI). And you know what?
Standards reduce the ability for products to differentiate/innovate, to a greater or lesser extent, from my understanding rather than experience, of course.
[And, wrt Mr. Bernstein's comments above, he does NOT hear Michael Hedges, "apparently".
"Michael, I hear you.
The main motivation behind Atom is to make it easier for developers to innovate. ... A valid criticism is that developers now will have to support two data formats, which creates additional overhead. This is true, and unfortunate."
The main motivation behind Atom is, as I've stated, to kill RSS2. This is now coming to light, and ANYbody can SAY that was
(cont. 4 of 4)
This consensus omitted almost ALL the developers in the known world, the opinions of folks from "BigCo", as well as the USER's pov. (Although there will probably be claims to the contrary.) How else do you explain a committee coming up with a spec that is INTENDED to NOT be backwards compatible?!?. And doing the thing in a wiki is great for giving the APPEARANCE of a consensus in the first place, btw, but that doesn't imply that there even IS a consensus does not really exist. See the thread over at Mr. Doval's if there is any question in this regard.]
(Ooops. Replace 4 of 4? with this
The main motivation behind Atom is, as I've stated, to kill RSS2. This is now coming to light, and ANYbody can SAY that wasn't the motivation, of course.
The two formats is more than "unfortunate". A whole LOT more than unfortunate, as it's coming to light that this so-called consensus decision was (at least sure appears to be) largely, and maybe even entirely, unnecessary.
And this "consensus" that the Atom folks talked about is a consensus in appearance only, drawn up by a few folks who joined up together primarily because they had an axe to grind.
This consensus omitted almost ALL the developers in the known world, the opinions of folks from "BigCo", as well as the USER's pov. (Although there will probably be claims to the contrary.) How else do you explain a committee coming up with a spec that is INTENDED to NOT be backwards compatible?!?. And doing the thing in a wiki is great for giving the APPEARANCE of a consensus
(cont. 5 of 5)
[And to reiterate, what I consider my Main Point:]
This consensus omitted almost ALL the developers in the known world, the opinions of folks from "BigCo", as well as the USER's pov. [So any CLAIM that Atom represents "the developers" is Highly Suspect, at the very least.] (Although there will probably be claims to the contrary.) How else do you explain a committee coming up with a spec that is INTENDED to NOT be backwards compatible?!?. And doing the thing in a wiki is great for giving the APPEARANCE of a consensus in the first place, btw, but that doesn't imply that there even IS a consensus does not really exist. See the thread over at Mr. Doval's if there is any question in this regard.]
[Please bear in mind this is not reflective of posts since last night around 7 (and was written prior to pseudo-blog to Mr. Kellan, above, btw).]
Tim, I just saw the 7:19 pm post, and those were the ones I was referring
to.
Mr. Bernstein, again from the Motivation page: "We'd like to make this just one format (Atom) and one protocol (HTTP)."
Worse yet, "Software will continue to support RSS for a long time to come, I expect. But that's the software's job, not the specification's. Nobody's throwing away the past here, we're just working on improving the future."
Please don't try to kid a kidder: This spec's sole "job" is to kill RSS. What could be plainer??? Yeah, call yourself "working on improving the future" if you wanna, because that's a pretty easy sell to the lame. [Uhhh... perhaps "naive" would be MUCH better than "lame".]
"Well, you've got me convinced. But I guess that's to be expected since I'm your literary foil. Yeah, I guess it is
(cont.)
"Well, you've got me convinced. But I guess that's to be expected since I'm your literary foil. Yeah, I guess it is. If there are any real skeptics out there, post your questions below and I'll try to answer them."
Yeah, right.
Don Park was a skeptic, and was labelled a troller for making a mere
suggestion to consider a (VERY possibly) better alternative.
So I think the ideals of Atom are great! But, as so often happens when the theory precedes the reality by a few years or decades, it's impractical (to be read, impossible) to implement. ["It's" meaning these ideals, not the spec itself.] Perhaps the spec itself is better than the notions behind the group that developed it, I dunno.
But what I sure DO know is that the spec is gonna be hijacked by Evan/Blogger/Google. I should add the word "probably", because icbw. But the fact is an implementation beats a spec by a FER piece, 99 times outta a hundred. I don't see any comments here about even
(cont.)
But what I sure DO know is that the spec is gonna be hijacked by Evan/Blogger/Google. I should add the word "probably", because icbw. But the fact is an implementation beats a spec by a FER piece, 99 times outta a hundred. I don't see any comments here about even WHAT it IS that Blogger IS actually implementing, since the spec isn't done (but that may have been posted elsewhere). [See Mr. Doval's blog, and perhaps other spaces around Blogaria. Btw, is Blogaria the ONLY (let alone best) way to devise a spec?!?!?]
Now iirc (and I may not) Mr. Bernstein, I've read your blog and liked it and you're a principle (if not THE principle) of the Eastgate publishing outfit. Either way, I don't mean to imply you don't know anything.
Don't mean to imply that a-TALL...
But when you say "I'm sure that after a while it (Atom) will also reveal flaws" that is a factual mistake. Because Atom has had a chance here to
explain it's benefits, and they've been pret
(cont.)
But when you say "I'm sure that after a while it (Atom) will also reveal flaws" that is a factual mistake. Because Atom has had a chance here to
explain it's benefits, and they've been pretty sparse. That's a flaw right there, and I'd say a pretty major one. And to say "so we can continue to move forward while putting off the inevitable necessity of replacing Atom with something else as long as we can"...?
Atom doesn't even exist yet as a spec. The idea that nobody can own the spec is highly spacious (to be charitable), and is a VERY untested theory. I don't like the notion that the computer industry should be revolving around these kinds-a untested theories, like it did in the dot-com era.
"Nobody owns the spec, but it will evolve in an EXTREMELY useful way over
the years, just naturally and beautifully" seems like a bunch-a new-age hype to me. Some people actually WANNA return to the dot-com era, when trillions of investor's dollars were waste
(cont.)
... when trillions of investor's dollars were wasted and but a few made out like bandits. I don't know many people that seriously DO wanna return to that.
So when you say "I still think Atom can succeed by allowing developers to easily deliver a better (and more differentiated) end-user experience."
Well, I hope you're right but I expect the worst at the same time. Because the worst is what I sure AM seeing, and one can find two opinions on ANY subject, Net being what it is. But the opinions I've seen here and on the wiki, from developers, stacks up pretty soundly to say that Atom is a royal PITA.
For a set of purported benefits, one of which is that it will eventually lead to RDF. And RDF wants to slip in the back door because it's not able
to compete in the marketplace, at least yet (not saying never will). So
presenting Atom as the li'l guys fighting against Dave's "first-mover"
Empire is disingenuous, to my eye anyway.
Btw, I mispoke above
(cont, last?)
Btw, I mispoke above. It just dawned on me that Google HAS hijacked Atom by
FUD of an impending implementation. And if the Atom group was nearly as
forward-thinking as the claims indicate, they would notice that this HAS and IS HAPPENING right now.
[I sure didn't make the point that Google doing this may very WELL be a GREAT thing!! Because that's how products get shipped, not by a bunch-a discussion by ego-filled, pedantic pundits, much of which is just elaborate theories designed to cover some (possibly simply) flaws in BOTH RSS2 and Atom which (probably) could BE FIXED EASILY with a MINIMUM of cooperation. I believe THAT is a better summary of Michael Hedges point, than what Mr. Bernstein posted above.]
Dave,
I didn't say you had done it alone. If I implied that inadvertently, I apologize. You definitely did solicit contributions from others, and in many cases incorporated it.
But, it was apparent that any suggested change that 'broke' existing software deployments (by which, to your credit, you did not mean just Radio Userland) was a complete non-starter. This is understandable, but it meant that the new version of RSS had to be not just backward compatible with old versions of the spec, but 'bugward compatible' with old versions of everyones existing software, and at least some of the behavior exposed by the attempt at adding an rss namespace *was* buggy, and *should* have been fixed rather than accomodated. Your suggested fix would have worked, but at the expense of making rss a permanent special case in the world of XML processing.
On the other side of that coin, you made it clear that nothing could be done to tighten the specification in any way that invalidated exi
(cont.)
On the other side of that coin, you made it clear that nothing could be done to tighten the specification in any way that invalidated existing applications that emitted RSS either. If RU and other existing software accepted a feed (no matter how badly formed), then the spec couldn't be tightned to say the feed was invalid, which basically meant that nothing could really be done about bad (from an XML POV) feed data. There was an opportunity there to do a corner-turn and get the world of RSS parsing in line with the rest of the XML processing world, but it didn't happen.
You added new optional functionality to the core spec that was already well (in fact, better) covered by existing namespaced RSS 1.0 extension modules (eg. pubdate vs. dc:date). The namespace 'olive branch' was supposed to allow people to leverage the work that had been done on these extension modules.
I *know* I suggested at the time that the specification at the very least include a simple and exp
(cont.)
I *know* I suggested at the time that the specification at the very least include a simple and explicit rule of precedence to cover the situations where both an optional core element and an overlapping namespaced extension element were present, in order to avoid any ambiguity, but it didn't make it into the spec (I thought that the namespaced element should have precedence if the client could parse both, you disagreed, but either way it needed to be unambiguous). In the absence of such a precedence rule, feed publishers had to pick one or the other of overlapping elements, rather than include both. Some vendors and publishers, for various reasons, chose the namespaced elements.
So next, you made a big foofooraw about 'funk'. Eventually you explained that you were complaining about using namespaced elements to replace functionality available as an optional core element. Well, hell, that means that for all practical purposes we can't continue using dc:date even though
(cont.)
[...] Well, hell, that means that for all practical purposes we can't continue using dc:date even though it predates pubDate, can't use dc:creator to specify author names without email addresses, and probably other examples I can't think of at the moment. This is the more sophisticated interpretation, mind. A simpler one (and one that I have heard from developers not as familiar with RSS) is 'namespaced extensions are bad'.
How is this *mess* supposed to make developers feel that RSS 2.0 is easily extensible? The only situation in which that seems completely true is when the extension is only intended to be used within a walled garden of some sort.
By contrast, extending Atom-the-format will be far simpler, follows the same rules as the rest of the XML processing world, and as a bonus, you get to use exactly the same extension mechanism for Atom-the-API, no ifs, ands, or buts.
"The main motivation behind Atom is, as I've stated, to kill RSS2. This is now coming to light, and ANYbody can SAY that wasn't the motivation, of course.
The two formats is more than "unfortunate". A whole LOT more than unfortunate, as it's coming to light that this so-called consensus decision was (at least sure appears to be) largely, and maybe even entirely, unnecessary."
jt, killing RSS is *not* the goal, nor does anyone I kn ow of who is involved with Atom think it will even have that side effect. RSS is here to stay as a delivery format, just as all old versions of HTML are here to stay. I don't know how to say that any clearer.
As for the decision for Arom to not be backward compatible with RSS, my response to Dave above should give some details as to why backward comaptibility is problematic. Sometimes you really do need to start fresh. If we're wrong, Atom will fail.
It would probably have been better if Evan's feed had been labled as 'experimental', b
(cont.)
It would probably have been better if Evan's feed had been labled as 'experimental', but I think you're reading a bit too much into the tea-leaves here. Atom is vendor neutral, only makes features required that most people have said should form the new baseline, incorporates the optional features that various vendors (large and small) have said they need in common, and thus provides less of a need (at least for a while) for vendor specific extensions.
Even if Atom does not end up being perfect (and it won't) it will provide a clear path forward for quite a while.
Oops. Looks like jt's rant that I responded to was deleted.
Michael, I didn't delete any posts.
Gah. Color me stupid. Feel free to go ahead and delete this post, my 'oops' post, and your response in between.
You lost about two dozen posts. Last night this was at about 138 posts, now down to 114.
Hmmm. Well, as far as I know, I'm the only one who has delete priviledges and I haven't deleted anything. Haloscan has been driving me nuts, though. I think it's time to switch commenting systems.
Well, no great loss. It ate a few hundred words of mine about printing presses, arguments over type faces, and the Federalist papers.
nothing important.
After so many years of berating Microsoft for just up and creating standards, we go and do the same ourself -- and somehow think that it's okay when it's not Microsoft?
Shame on us.
Hmm. Richard, we berate MS for doing something like that without seeking outside input and without being willing to share the design process with other stakeholders. Nothing could be further from how the Atom design process has progressed. Just about every contribution, discussion, argument, decision, backpedal, vote and whim has happened in public, on mailing lists, weblogs, and the wiki. to join the process all anyone has had to do is show up and participate.
You can't really get a more open process than that. The resistance that you're seeing from the Atom advocates to going back and forking RSS instead, is because we already *had* these discussions, and decided otherwise.
While there is sometimes merit in criticising design decisions after the fact when they are made in secret and with a hidden agenda (because presumambly the people who made the decisions don't have your interests in mind, otherwise why wouldn't they have invited you earlier?), these decisions about Atom
(cont.)
[...] these decisions about Atom were made (and continue to be made) completely out in the open.
There is no point in revisiting old consensus decisions unless major facts have changed in the meantime. The facts are the same, Atom's goals are the same, the participants are largely the same, so the decision to start the format from scratch should stand.
Simple as that.
You are right ofcourse... But... http://www.buy-games.narod.ru/
Okay, ik ga ze plaatsen op m'n web-log. http://www.thispot.com/small-bus...ess-
grants.html
Please check the sites about- Tons of interesdting stuff!!!
Very good for ad placement...
So watch for Google to output ad management tools based on Open Office.
And a whole Ebay-style ecosystem to use the tools.
And lots of developers to build out the toolkits...
generic cialis information including how to buy online at cheap prices , find out about generic cialis here.
discount pharmacy information including how to buy medications online at great prices , find out about discount pharmacy here.
online pharmacy information including how to buy medications online at great prices , find out about online pharmacy here.
canadian pharmacy information including how to buy medications online at great prices , find out about canadian pharmacy here.
canada pharmacy information including how to buy medications online at great prices , find out about canada pharmacy here.
Generic Cialis information including how to buy online at cheap prices , find out about Genric Cialis here.
Mexican pharmacy information including how to buy medications online at great prices , find out about Mexican pharmacy here.
foreign pharmacy information including how to buy medications online at great prices , find out about foreign pharmacy here.
international pharmacy information including how to buy medications online at great prices , find out about international pharmacy here.
Just to be flippant for a moment:
Anyone else notice the similarities getween the Bush administration and the Borg?
"Resistance is futile! You will be assimilated into the New World Corporate Order!"
On a serious ending note, the Bush administration has just declared war on everyone
else in space. I'm beginning to wonder if these clowns aren't rogue Scientologists
who took L. Ron Hubbard's disgusting science-fiction vision of A future and are
trying to make it THE future.
Please find time to vist site:
Desktop video conferencing
Desktop video conferencing education
Real time desktop video conferencing
Block Dialers
Voip Phone
Voip Provider
Web System Integration
Collection Predictive Dialer
Predictive Dialer System
IVR System
Blogging IS time consuming. I spend about 4 hours a day on Lost Remote,
from content to maintenance to development. Add that to my full-time TV job and
sleep is an oddity.
But it's worth it. I enjoy having an unfiltered voice -- which is a luxury in
today's big media world.
Internet conferencing solution
Internet web conferencing
Internet video conferencing software
Internet conferencing solution
Internet conferencing software
Internet telephony vs. video conferencing
Filipinos love a free ride. Well, who would want to pay for something
one can get for free, right? But there are some very strange people
sending me e-mails lately. Two were pleas for advice on marriage
annulment. One was for a logo of the Koalisyon ng Nagkaisang Pilipino
(KNP), of which Fernando Poe Jr. is the standard-bearer.
I was nice to the women asking for advice on marriage annulment. But,
please, no more. Just because a lawyer blogs about her opinions doesn't
mean she is offering legal advice for free. Enough.
To the person asking for a logo of the KNP... does it look like I am
supporting KNP? Hello? Read my posts before making such a ridiculous
request.
ERP Software/a>
Business productivity
Automotive
Application Development
Banking
BPO
Call Center
Content Management Software
Construction Software
Database Management
EAI Software
GIS software
There are too many complaints on the internet these days. We all
seem to be bitching about something. It’s either those damned 13 year olds
that are bringing the intelligent World Wide Web to it’s metaphorical knees.
Or it’s something about how your e-friend club kicked you out despite years
of dedication and service. People are bitching because they are banned and
because other people haven’t been banned yet. Kids are threatening to slash
their wrists because people refuse to leave comments on their live journal
entrees. I’m bitching because other people are bitching. It’s a cruel cycle.
Long Distance Learning
Ecommerce Software
Help Desk Software
Inventory Software
Logistics Software
Manufacturing Software
Medical Billing Software
MSDS Software
Payroll Software
POS Software
Project Management Software
Scheduling Software
Security Software
Software
Purchase
name the last 3 states you visited
1. new york
2. pennsylvania
3. rhode island
Web phone conferencing
Online phone conferencing
Internet phone conferencing
Phone service conferencing
Phone conferencing solution
Personal phone conferencing
Phone conferencing services
Free telephone conferencing
Audio Conferencing
Audio conferencing services
Audio conferencing web solution
Audio conferencing web
Audio conferencing system
Audio conferencing company
Audio conferencing phone
Audio conferencing service
Audio conferencing solution
Online audio conferencing
Data teleconferencing
Audio video conferencing
Audio video conferencing software
I'd like to blame the weather for my mediocre content and laissez-faire
posting lately.
Ok. Not a problem. I'll blame the weather.:^)
Even comment spammers don't seem to have much energy. I have one that consistently
gets through the spam blocks and leaves new-age-cyber-Hallmark- type quotes.
Real Time Conferencing
Site Map
FAQ's
Voip Call Generator
Predictive Dialers
Predictive Dialers Software
Predictive Dialers Types
Predictive Dialers Technologies
Used Predictive Dialers
Predictive Dialers
Predictive Dialing
CTI
CRM
IVR
Voip Architecture
I was nice to the women asking for advice on marriage annulment. But,
please, no more. Just because a lawyer blogs about her opinions doesn't
mean she is offering legal advice for free. Enough.
To the person asking for a logo of the KNP... does it look like I am
supporting KNP? Hello? Read my posts before making such a ridiculous
request.
Please visit these few sites :
BPO
CRM
video conferencing
conferencing
audio conferencing
ERP
Software/a>
accounting software
This blogs page reveals that we are not here to comment but comment is being written by ownselves. Lol!!! here we say that this blog page is quite familiar to me as i have seen these commment earlier in another site. I dont know if that was the same site but i m sure that it is same page which i saw once. Most probably, it wud be the same site. Nice blog page u have.but I have always looked for a possibility to find information as quick as I can and i got it from ur blog page. Thanks.
Cialix, Cialas, Cailis, Cyalis, Lavitra,
Levetra, Livitra, Livetra, Viagrx, Semanax
There is a good rss syndication tool for php, magpies rss
car rental
hhjt
Here is upcard online roulette hand spikes fold.
All face free craps practice rock cowboys million tipping crown rake crack?
Rate dollar craps table http://www.trinbagoauto.com/craps.htm fill value!
A line tutorial island juice keno bump shoe split line baccarat wheels pat variations dollar stack cage easy under high.
temperature
thermocouple thermocouple
welder
http://adult.paradise.free.fr hi scoble 5632
Free Porn Movies: http://perso.wanadoo.fr/montpell...ntpellier-sexe/
scoble 5632
hmmm .
amount of effort required to solve those problems by extending RSS 2.0 is far less than the Atom feed approach and will definitely cause less confusion.
J.Samuel: I have seen so many site putting themselves as online pharmacy, but after making lot of comparison, I figure out that http://www.geocities.com/viagra_dose is the one and only true pharmacy, as it is not only providing various medication at best possible price, but it is also putting the fact about the medication as, how to take the medication, what's the proper dosage, side effects, possible drug interactions and precaution to be taken while taking the medication.
Telefonsex Fetisch - Telefonsex Anal - Telefonsex mit Bild
lon
Finanzen, Finanzen - Internet, Internet - Kinderseiten, Kinderseiten
oq
Great Job
Porno Gratuit: Club Libertin 100% Amateur Gratuit : http://1.porno.gratuit.free.fr scoble 5632
http://www.pregnancy.net.in
The period during which a developing fetus is carried within the uterus. In humans, pregnancy
averages 266 days (38 weeks) from conception to childbirth. Traditionally, pregnancy duration
is counted from the woman's last menstrual period, which adds roughly 2 weeks to gestational
age. This is how physicians arrive at a pregnancy length of 40 weeks (280 days).
http://www.pokkers.org
the most popular of a class of games called vying games, in which players with
fully or partially concealed cards make wagers into a central pot, which is awarded
to the player or players with the best combination of cards or to the player who makes
an uncalled bet. Poker can also refer to video poker, a single-player game seen in
casinos much like a slot machine, or to other games that use poker hand rankings.
http://www.flowers-shop.org
In modern times, people have sought ways to cultivate, buy, wear, or just be around
flowers and blooming plants, partly because of their agreeable smell. Around the world,
people use flowers for a wide range of events and functions that, cumulatively, encompass
one's lifetime
http://www.123pethealth.com
pet health insurance, pet health care, pet health question, pet health care information, pet health care insurance, dog health insurance pet, pet health information, pet health plan, pet dog health, pet health supply, online pet health, holistic pet health, pet health info, pet animal health, pet health food
Commenting by HaloScan
