Sam asked
> P.S. Why is this on atom-sytax? Is there a concrete proposal we are talking about here? Is there likely to be?

I launched this discussion here for three reasons:

1. Everyone who care's about it is probably already here

2. Main discussion about the syntax is pretty much complete so there is no real risk of derailing anything

3. If there was no already accepted solution to the problem, this would be a logical place to begin hunting for and discussing the solution

That said, however, is there a better venue that you could suggest?

Capping out the conversation a bit, Bob Wyman's RFC3229+feed proposal, once written up into an Internet-Draft, will provide the solution that I'm searching for (e.g. the ability to catch up on what has changed in a feed over a given period of time). The XMPP Push model would likely not be implemented in the case I'm considering but I couldn't rule it out completely. I believe it is Bob's intention to draft up the RFC3229+feed and pitch it to this group for discussion.

Sam Ruby wrote:


Joe Gregorio wrote:

On 6/17/05, Bob Wyman <[EMAIL PROTECTED]> wrote:

Joe Gregorio wrote:

The one thing missing from the analysis is the overhead, and
practicality, of switching protocols (HTTP to XMPP).


       I'm not aware of anything that might be called "overhead."


I was referring to switching both the client and server from running
HTTP to running XMPP. That may not be practical or even possible
for some people. Yes, I understand that you run this right now.
Yes, I understand that you run a business doing this right now.
Yes, I agree that your solution is one way to solve the problem.

Do you agree that 99.99% of all syndication is done via
HTTP today and also offering an HTTP based solution would be of value?


Joe, I'd be careful with how you structure this argument. It could be applied in a different context, for example:

  Do you agree that 99.99% of all syndication is done via HTTP GET
  and POST today and offering a solution based only on these two
  verbs would be of value?

One can go down this path and cater to the least common denominator always, or one can say that perhaps MIDP 1.0 phones are not particularly well adapted to perform complex editing tasks beyond simple GET and POST.

Perhaps HTTP is suited to a wide, but not universal, range of applications dealing with relatively coarse and relatively infrequently updated content; and XMPP is well suited to a different -- always on, firehose -- set of applications, with a wide overlap between the two.

And perhaps they could be combined. I could see a future where there was a "feedmesh" backbone with nodes exchanging data via XMPP, serving content out to the rest of the universe via HTTP.

- Sam Ruby

P.S. Why is this on atom-sytax? Is there a concrete proposal we are talking about here? Is there likely to be?



Reply via email to