A Response to Danny Ayers
I just ran across Danny Ayers' critique of the NGAPI, and I know I'm late to the party, but as the guy responsible for this API I should explain a few things. First of all, a great deal of this work was done in January-February of this year, when Atom was much less far along the design path. I'm one of the dummies who implemented something significant based upon Atom 0.3 and personally was not comfortable with doing any more work with Atom until 1.0 was an official IETF spec.
The choice of OPML and RSS was not so much to reuse our code internally as to reuse all the other code out there that aggregator authors have written. My intention was to produce an API that could be implemented in stages, with everything you don't want as ignorable. I wanted to set the barrier to implement our API as low as possible. As far as the extensions to OPML and RSS being geared to our particular implementation needs, I'm missing the point of this critique. How else would we communicate read states? If I've missed some prior art (non-proprietary prior art, that is), I'd really like to know.
I also considered SIAM and Attention.xml. SIAM is sort of moot, as Dare's indicated that he's not pursuing it anymore, and shares the same issue as attention.xml: we might implement it, but we'd be just about the only ones who could read it. As Sagi indicated, some aggregator authors are having an easy time implementing the NG Sync API, which is exactly what I was hoping for. I won't rule out NewsGator implementing Attention.xml, but I need to reiterate that I wanted to make the barrier to adoption as low as possible.
With respect for the Token, we plan on supporting Conditional GET in Feed.aspx and Subscription.aspx, and regret not doing this in the first place. The problem is that the intent of the sync token is somewhat different from ETag: the idea with a sync token is to omit any items that the caller has already seen. Whether or not we'd be more bandwidth-efficient with conditional get is still an open question, but in any case, this is SOAP we're talking about here - Conditional GET isn't an option in SOAP.
So yes, this does matter to me. NewsGator is a small company and we're stretched thin, and I suck at writing documentation. All I can say is that we take this stuff seriously and I make every effort to make sure the docs and schemas are accurate. I'll admit to a number of mistakes: I wish I'd been more uniform in naming operations and in the types of parameters these operations take, for example. And I mentioned Conditional GET as an omission I regret. But all this stuff is fixable, and with NG Outlook and FeedDemon dependent on the API, there were significant time constraints.
Oh, and as far as the comment posted by Gerald, I've never had to deal with Claria's products, so I can't say I feel his pain, however, NewsGator is the name of the company, hence having the name on the API seems appropriate. Really, I feel like it's a horse that's been beaten to death: Claria and NewsGator are unrelated companies and further discussion of the coincidence in naming is starting to feel like trolling.