If it makes you feel any better, I suspect the problem is more their fault than yours. It seems even Newgator's Outlook Edition doesn't properly mark things as read.

All in all, I've quite disappointed in the direction NG is heading. It's not solving the problems I have - the synchronization only added a level of complexity and bloat that doesn't buy me anything. (I already have Exchange to keep everything in sync, and that actually marks things read across all instances!)

I've been auditioning replacements, including OL12's native functioanlity - although unfortunately I haven't found the right product just yet. (I'd prefer to switch just once, not having to deal with the hassle of moving from piece to piece).

(And yes, I've recommended RSS Bandit to many others - even installing it for my parents last weekend - but I personally hae a system built on Outlook).

I was looking forward to NG syncing. A pity.

Thanks anyway. Me and, I'm sure, many others appreciate all the work you guys do to put out such an awesome, free aggregator.

Is one of the bugs you're going to fix the fact that your "Dares RSS Bandit Blog" doesn't show unread items, but the items appear when you use the Unread items search? Every other feed seems to behave itself except that one.

Really? Man... was it something that could just be fixed with REST?

Rumor has it that the SOAP lib that NetNewsWire uses won't work with the NewsGator SOAP impl.

Give me REST or give me death.

Stu,
I've nevr seen a bug report or forum post about this bug. So the answer is "No", it won't be fixed in the bugfix release.

Kevin,
I'm using Visual Studio to build RSS Bandit so working with SOAP is not a hassle. The complexity of the API has to do with its expected usage model differing from how the synchronization model works in RSS Bandit. Also I think it has bugs.

Dare, you're correct that the expected usage model is the source of the problem here, as we discussed via email a while back. As with other feed APIs, NewsGator's assumes that our service will be the source of your feeds, and we didn't anticipate that developers might want to use it differently (ie: uploading/downloading state in bulk, as you're doing). Nothing wrong with that approach - just that we didn't think about it until RSS Bandit attempted it :)

As you're no doubt aware, a big part of the problem is uniquely identifying posts (the bane of RSS reader developers everywhere!). When NG is used as the source, we can uniquely ID each post so you don't get duplication, etc. But because we're stripping GUIDs (a problem we're planning to address, btw), it's error-prone trying to match a post from the original feed with that in the NG feed. Even after we've resolved the GUID stripping, though, there's still the problem of thousands of feeds out there that don't uniquely ID each post (a situation that makes me appreciate the NG API, since it always provides unique IDs).

I do agree that our SOAP-based API is more complex when compared to REST APIs, but it's also very powerful, enabling you to do far more than simpler approaches I've seen. And FWIW, in FeedDemon's case when a feed is "synched" with NewsGator, I retreive it using the HTTP POST version of NG API's "GetNews" method, which was *very* simple to implement.