Thomas Broyer wrote:
I beg to differ. I think the incremental state of a feed is very relevant
to paging. If the aggregator does not know that a feed is non-incremental
it will not be able to process the feed document in a meaningful manner.
Yes, but that's orthogonal to paging.
I think I see where the misunderstanding has arisen here. We don't agree on
what constitutes paging in a non-incremental feed. You think it means
splitting a single feed into multiple pages whereas I interpret the pages as
being a history of past feeds. With your interpretation the incremental
state is irrelevant - with mine it's very relevant.
You're not describing a "search feed" (or maybe more a search *result*
feed, like OpenSearch result feeds) but a "filtered aggregate feed" (as
published by PubSub).
Actually I was thinking of something somewhere in the middle. Like when you
do a search in Google Groups it offers to notify you of new results via
email. I would have thought that would be a standard feature for any search
service that provided results in a syndication format. I mean what's the
point of having something you can subscribe to if it doesn't change?
This is all very interesting, but not possible without more link
extensions which don't exist yet.
Wait a bit and I'll propose them for registration. When they'll exist,
what would become your argument?
I think what you're suggesting is overly complicated and not strictly
necessary. However, there's nothing stopping you proposing such an
extension. My opinion is just my opinion. If you can get support for it,
great.
The only thing that matters at the moment is whether you're happy with
Mark's current proposal for next/prev. If you are then we can move on. If
you aren't, you should probably be taking up your case with him.
With what we have so far we can do incremental feed archives; we can do
at
least some form of searching; we can do non-incremental feeds (of the
"Top
10" variety) with history. I think that's a good start.
But we also want paged non-incremental feeds (OpenSearch result feeds),
while "non-incremental feeds with history" have not yet proven to be
needed.
I still don't see why OpenSearch result feeds can't be implemented as
incremental feeds. Either they're being used as a one-off search and you
can't subscribe to them (in which case there is no difference between
incremental and non-incremental), or they're being updated with new results
over time (like a filtered aggregate feed) in which case I would think they
have to be incremental.
As for "non-incremental feeds with history", I can't point to a specific
site that is using something like that, but I know it has been requested
before. It's possible it was just a hypothetical "it might be useful if..."
type of request though.
I'm proposing previous/next linking from chunk to chunk inside the same
snapshot and adding a new link relation (or set of link relations) for
linking from snapshot to snapshot.
Do you now see what I'm talking about?
I understand what you're talking about, but I just don't see the need. I
would have expected a non-incremental feed to be a single Atom document. My
reason for wanting paging is so that a user doesn't need to fetch data that
he already has - this can never be a problem with a non-incremental feed
because it doesn't grow. That leaves the next/prev links free for use as a
history of past snapshots.
Once again, this is just my opinion. I don't expect you to agree with me.
I'm sure the market will make its own choices about how best to use these
extensions. If it turns out my opinion is in the minority, you may well find
me changing my mind in the future - it wouldn't be the first time.
Regards
James
