2006/6/8, Mark Nottingham [EMAIL PROTECTED]:
On 2006/06/07, at 11:40 PM, Thomas Broyer wrote:
My main concern is that RFC3229 w/ feeds is being deployed more and
more widely and is still not even an I-D (or I missed something).
I have that concern as well.
I am also concerned that
Thomas Broyer schrieb:
If I read RFC2616 correctly, nothing prevents the latest entries
only and full representations (or any representation of the same
resource) to share the same entity-tag, i.e. nothing prevents a server
to assign an entity-tag to a resource rather than its representations.
2006/6/9, Julian Reschke [EMAIL PROTECTED]:
I think this is a misunderstanding of how HTTP/1.1 is supposed to work.
If a server returns the same ETag for different entities returned for
the same URL, this will cause breakage of caches. You may want to
re-read Section 13.6 of RFC2616
2006/6/8, James Holderness [EMAIL PROTECTED]:
Mark Nottingham wrote:
Are you talking about using ETag HTTP response headers, If-Match request
headers, and 304 Not Modified response status codes? That's a gross
misapplication of those mechanisms if so, and this will break
intermediaries
Thomas Broyer wrote:
What you described is RFC3229 w/ feeds [1], but you failed to include
the new request and response headers and the specific status code,
which are necessary because you're changing the behaviour of
If-None-Match and 304 (Not Modified) as defined in HTTP/1.1.
Yep. Sorry,
2006/6/8, James Holderness [EMAIL PROTECTED]:
Thomas Broyer wrote:
That means you need to keep entry revisions as well, so that if an
entry is updated while a client is navigating the paged result set, it
is sent the old revision (corresponding to the date parameter).
Why? If an entry has
On 2006/06/07, at 11:40 PM, Thomas Broyer wrote:
My main concern is that RFC3229 w/ feeds is being deployed more and
more widely and is still not even an I-D (or I missed something).
I have that concern as well.
I am also concerned that RFC3229 is an extension of HTTP, but some
Thomas Broyer wrote:
Could you read my recent mails in this thread and confirm that it's the
case?
I'm sorry, but I can no longer participate in this discussion. I hope
everything works out ok.
Regards
James
Definite +1
+1 as well.
I'm going to reserve judgement until I see what exactly it is you're
proposing, but I'm not particularly keen to change our existing
implementation.
Our of curiosity, do you know of *any* client applications that actually
support feed paging? Or have expressed an intention to support feed
We have a client that is specific to our Open Activities platform that
uses feed paging. It's not a general feed reader, tho. I believe our
general feed reader component will support paging (maybe does, haven't
checked on it in a while).
- James
James Holderness wrote:
I'm going to reserve
On 2006/06/07, at 4:26 AM, James Holderness wrote:
I'm going to reserve judgement until I see what exactly it is
you're proposing, but I'm not particularly keen to change our
existing implementation.
Understood. I've been reluctant to change the spec for just that
reason, but the split
Mark Nottingham wrote:
Our of curiosity, do you know of *any* client applications that actually
support feed paging?
I think most of the use cases for paging have to do with things like
GData, OpenSearch, etc -- i.e., query results. That sort of thing isn't
targetted at desktop
I think most of the use cases for paging have to do with things like
GData, OpenSearch, etc -- i.e., query results. That sort of thing
isn't targetted at desktop aggregators AFAICT; it seems to be more for
machine-machine communication, or for browsing a result set.
Which sets the
James Holderness wrote:
Mark Nottingham wrote:
Our of curiosity, do you know of *any* client applications that
actually support feed paging?
I think most of the use cases for paging have to do with things like
GData, OpenSearch, etc -- i.e., query results. That sort of thing
isn't
On 2006/06/07, at 9:03 AM, James Holderness wrote:
As for machine-machine communication, if these feeds aren't meant
for desktop aggregators then does it really matter that they
function differently? You can describe one algorithm for use in
machine-machine communication and another for
You can use Atom for news feeds too?!
Wow! So many uses, so little time (please know I am being
sarcastic... Just agreeing with Sylvain's point in my own
personalized style sort of way ;)
On 6/7/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote:
I think most of the use cases for paging
Mark Nottingham wrote:
These are pretty much the assumptions that I was making previously. The
degree of precision that FH currently provides isn't desirable for search
results. Feed History also requires that the server maintain state about
a particular feed, which is unworkable for
2006/6/7, Mark Nottingham [EMAIL PROTECTED]:
The degree of precision that FH currently provides isn't desirable
for search results. Feed History also requires that the server
maintain state about a particular feed, which is unworkable for
search results; e.g., to implement feed history for
On 2006/06/07, at 11:16 AM, James Holderness wrote:
Mark Nottingham wrote:
These are pretty much the assumptions that I was making
previously. The degree of precision that FH currently provides
isn't desirable for search results. Feed History also requires
that the server maintain
Mark Nottingham wrote:
I'm not sure how ETags and 304s come into it -- it sounds like you're
proposing using either the entry-level updated date or the entry- level id
as input to a server-side function to select a set of entries from the
feed. Can you paint out your proposal in protocol
Are you talking about using ETag HTTP response headers, If-Match
request headers, and 304 Not Modified response status codes? That's a
gross misapplication of those mechanisms if so, and this will break
intermediaries along the path.
Even if it's cast as a query parameter in the URI (for
Mark Nottingham wrote:
Are you talking about using ETag HTTP response headers, If-Match request
headers, and 304 Not Modified response status codes? That's a gross
misapplication of those mechanisms if so, and this will break
intermediaries along the path.
For the first page I'm talking
I've been talking to a number of people face-to-face about Feed
History and the use cases for it, and I've come to a position where I
believe there are two major use cases out there for putting together
multiple feeds to form one big, virtual feed.
1) So-called incremental feeds, where
Mark Nottingham wrote:
I've been talking to a number of people face-to-face about Feed
History and the use cases for it, and I've come to a position where I
believe there are two major use cases out there for putting together
multiple feeds to form one big, virtual feed.
1) So-called
25 matches
Mail list logo
