This is a good venue. I think XMPP and polling can be explored.
But for the needs of BlogEd [1] on which I am working, and for my
personal needs,
I would really like us to introduce an extension to the link concept,
to provide
a pointer to the next page in a historically ordered sequence of feed
documents.
For many people who have dumb internet connections with very minimal
servers, the
xmpp solution requires a lot more technology than we have available
or want to be
bothered with. Something like:
<link rel="http://.../next"; href="http://bblfish.net/blog/archive/
2005-05-10.atom">
would be really useful. It requires only a working apache on the
server side.
On the client side it is really simple to follow. The client just
needs to have access
to the base feed url, and can follow these links through all the
change history of the
feed if he wishes.
It would allow me to have a:
- a remote backup of my blog
- provide the means to synchronize it between two editors
- allow clients and aggregators to get a complete historical view
of the feed.
And it comes at really no cost, since all it requires is for us to
mint a new "next"
url. So how does one go about extending atom? This was meant to be a
feature of it,
and especially of the link concept.
Henry Story
[1] https://bloged.dev.java.net/
[2] http://bblfish.net/blog/
On 18 Jun 2005, at 06:27, James M Snell wrote:
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?
