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
This relates to work that we are doing with the publishing protocol, but
is syntax related.
In an implementation of APP a single entry can appear both in the APP
collection and in any number of arbitrary feeds that the site
subsequently offers.
These feeds / collections can be optimized
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
You can have two entries or feeds with the same id, as long as they
have different updated time stamps.
It's very much the same as you being Robert Yates all your life, but
having different sizes throughout your life. At any point in time you
have all the same properties...
Henry
On 7
You can have two entries or feeds with the same id, as long as they
have different updated time stamps.
It's very much the same as you being Robert Yates all your life, but
having different sizes throughout your life. At any point in time you
have all the same properties...
/me wonders
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
* Sylvain Hellegouarch [EMAIL PROTECTED] [2006-06-07 20:20]:
/me wonders how long before a wiki engine based on Atom :)
You mean http://www.xml.com/pub/a/2004/04/14/atomwiki.html? :)
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
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
Henry Story wrote:
You can have two entries or feeds with the same id, as long as they have
different updated time stamps.
That's not quite accurate. Two entries with the same atom:id may appear
within the same atom:feed only if they have different atom:updated
elements. The spec is
2006/6/7, Henry Story [EMAIL PROTECTED]:
You can have two entries or feeds with the same id, as long as they
have different updated time stamps.
It's very much the same as you being Robert Yates all your life, but
having different sizes throughout your life. At any point in time you
have all
Yes, I know, the atom syntax doc does not make statements about what
happens in different feeds. But that does not mean that we are not
forced logically to a conclusion. There was a very in depth
discussion of this by the way on the atom semantics [1] mail list
this February.
I think
After my earlier post about discoverability of related feeds, I realized
that I had neglected to explain the background behind what I'm thinking
about fully. Here are all of the gory details:
http://journals.aol.com/panzerjohn/abstractioneer/entries/1338
I'm attempting to promote the use
2006/6/7, Robert Yates [EMAIL PROTECTED]:
Thomas Broyer wrote:
and that this is needed because entries
might not always be atomically retrieved (otherwise, permaLinks
would been enough).
I don't understand what you mean atomically retrieved and hence why
permaLinks would not have been
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
John Panzer wrote:
I'm attempting to promote the use of explicit licenses in feeds, and
Creative Commons is one great source of predefined licenses suitable for
the kinds of things that people want to use feeds for today:
Creative Commons only covers a very small subset of what's needed
Elliotte Harold wrote:
John Panzer wrote:
I'm attempting to promote the use of explicit licenses in feeds, and
Creative Commons is one great source of predefined licenses suitable
for the kinds of things that people want to use feeds for today:
Creative Commons only covers a very small
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
Hey John,In this example, does rel=license represent a tagged reference or the URI to the location of the license?On 6/7/06, John Panzer
[EMAIL PROTECTED] wrote:Elliotte Harold wrote:
John Panzer wrote: I'm attempting to promote the use of explicit licenses in feeds, and Creative Commons is one
I don't want to speak for John, but in the feed thread draft, it's both.
The href is intended to be dereferenceable to retrieve some document
describing the license.
- James
M. David Peterson wrote:
Hey John,
In this example, does rel=license represent a tagged reference or the
URI to the
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
Le 06-06-08 à 05:17, John Panzer a écrit :
I'm attempting to promote the use of explicit licenses in feeds,
and Creative Commons is one great source of predefined licenses
suitable for the kinds of things that people want to use feeds for
today:
Yes, I intended to refer to James' feed license extension:
http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/
(James, I think you meant "feed license draft" rather than "feed thread
draft", right? :) )
James M Snell wrote:
I don't want to speak for John, but in the feed
Doh! Yes, sorry, I've had feed thread on the brain lately.
John Panzer wrote:
Yes, I intended to refer to James' feed license extension:
http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/
(James, I think you meant feed license draft rather than feed thread
draft, right?
Okay, cool... This is the first I've seen this, but that obviously nothing of any great concern.I guess my next question is the same as what what you, Elliotte, and Karl have already made the primary focus of this thread,
* Beyond providing a way of referencing what license(s) applies to any given
32 matches
Mail list logo
