"Parser" said the really wrong thing to me. Notification and normalization seems to be what's going on but you still need to parse the Atom feeds. "Parser" says to me something like http://www.feedparser.org/ . (Kind of by definition, a "web service" to "parse" another web service is absurd.)

I'm not saying this to be critical, just to let you know what I saw when I tried to read your site.

Thanks for the feedback... how would you name our service then? or at least : how would you describe it now that you know what it is?

I am terrible with names. Notification and normalization are the key words I came up with, but those are descriptive, not names.

Very nice service. I would've used it for my project had it been available when I started, but I had to build most of the features you listed in house (we pull about 80K feeds). One feature that might be interesting to add is returning the results in json format since that's easier to parse now that most modern languages have that built it. And, by the way, are you aware that Google offers similar APIs? They restrict using it to personal and non-profit, so I couldn't use it.

I know of Google's Feed API : http://code.google.com/apis/ajaxfeeds/

But AFAIK, this API doesn't offer to actually do the polling for you. In the end, you would still need to spend a lot on BW to guarantee you get the updates in a timely manner. Also, (and that goes with the previous point) they cache the results from feeds... which is really not what we want to ensure fast detection of updates.

I would be interested by this service for a web site I'm building, but:

  * dealing with XMMP seems more complicate to me than using existing RSS libraries
  * 100% uptime required on the client side
  * no Perl library

Right now, it seems to be more complicate to use your service than doing it myself. Maybe because I plan on monitoring only about 2500 feeds...

Hey Jusob,

We actually launched on Monday. We have a Perl library coming so that you don't even have to know that it's XMPP as a protocol.

We also have a webhooks API if you really want to stay in the HTTP realm ;)

@superfeedr me if you need help on anything!

Funny, my first name is Julien :-)

I'll be busy for a while, I'll probably take a better look after july 4th.

Real time as in 15 minutes. Definition of real time is really variable these days.

Well.. 15 minutes is the limit. We actually have a lot of ways to stay below 15minutes and even below 1minut quite often!

Actually, I want to point out that "realtime" doesn't mean "instantaneous"... accordint to Wikipedia (http://en.wikipedia.org/wiki/Real-time_computing):

In computer science, real-time computing is the study of hardware and software systems that are subject to a "real-time constraint"

We're committing at improving our detection time, but right now, we can only guarantee 15minutes.

Can you turn off that jazzy background please. I feel dizzy looking at all those stripes.

Arf... good point!