You've written on your blog that you want to see more 304
responses. Well, I would suggest that what you *really* should want is more
226 responses -- 226 is the success code for an RFC3229+feed GET
operation.
I like so agree. 226 support would be highly commendable for
everyone,
--On May 5, 2005 10:53:48 AM -0700 John Panzer [EMAIL PROTECTED] wrote:
I assume an HTTP Expires header for Atom content will work and play well with
caches such as the Google Accelerator (http://webaccelerator.google.com/).
I'd also guess that a syntax-level tag won't. Is this important?
Actually, as I recall, last time this came up (proposed by Walter
Underwood), someone pointed out accurately that RSS2 has had this
functionality for a long time and that nobody ever really implemented
it; thus there was a strong vote from experience against such a
feature. -Tim
There is no
You can do that with the Expires response header. Everytime the
resource is requestef, serve it with a value of now +
minimumrefreshinterval.
Ah. I see what you mean. Thank you.
The problem is that when you say You can do that now with the Expires
response header - I can't. It's a
On 5/5/05, Andy Henderson [EMAIL PROTECTED] wrote:
convincing the WG, I would simply point out that a mechanism widely
available to, and understood by, feed providers and aggregators cannot do
harm and has the potential to do a great deal of good.
Not to be flippant, but we have one that's
--On May 5, 2005 8:15:10 AM +0100 Andy Henderson [EMAIL PROTECTED] wrote:
here is no RSS2 feature I can see that allows feed providers to tell
aggregators the minimum refresh period. There's the ttl tag. That was, I
believe, introduced for a different purpose and determines the Maximum time
On 5 May 2005, at 1:54 pm, Andy Henderson wrote:
I've no way to demonstrate aggregator use except my own - even
though I
support a tiny community I do observe and enforce the ttl tag.
You seem to want the ttl element so that you have the publisher's
permission to check less often. Why not just
--On May 5, 2005 8:07:15 AM -0500 Mark Pilgrim [EMAIL PROTECTED] wrote:
Not to be flippant, but we have one that's widely available. It's
called the Expires header.
You need the information outside of HTTP. To quote from the RSS spec
for ttl:
This makes it possible for RSS sources to be
You seem to want the ttl element so that you have the publisher's
permission to check less often. Why not just do so anyway if it causes so
many problems? If that degrades the user experience too much, you're free to
check more often. How is the ttl element useful to you?
I allow anyone to
On 5/5/05, Walter Underwood [EMAIL PROTECTED] wrote:
You need the information outside of HTTP. To quote from the RSS spec
for ttl:
This makes it possible for RSS sources to be managed by a file-sharing
network such as Gnutella.
Ignoring, for the moment, that this is a horrible idea and
On Thu, May 05, 2005 at 08:07:15AM -0500, Mark Pilgrim wrote:
Not to be flippant, but we have one that's widely available. It's
called the Expires header. I spoke with Roy Fielding at Apachecon
2003 and asked him this exact question: If I set an Expires header on
a feed of now + 3 hours,
On May 5, 2005, at 16:24, Walter Underwood wrote:
--On May 5, 2005 8:07:15 AM -0500 Mark Pilgrim [EMAIL PROTECTED]
wrote:
Not to be flippant, but we have one that's widely available. It's
called the Expires header.
You need the information outside of HTTP. To quote from the RSS spec
for ttl:
co-chair-hat status=ON
Warning: we are into the end-game. What really counts is the set of
outstanding Paces. When Paul and I are going through the list to
figure out consensus calls, emails that don't have a Pace in the
Subject line are apt to get ignored.
So I'm not sure this endless
* Henri Sivonen [EMAIL PROTECTED] [2005-05-05 18:35+0300]
On May 5, 2005, at 16:24, Walter Underwood wrote:
--On May 5, 2005 8:07:15 AM -0500 Mark Pilgrim [EMAIL PROTECTED]
wrote:
Not to be flippant, but we have one that's widely available. It's
called the Expires header.
You need
I assume an HTTP Expires header for Atom content will work and play well
with caches such as the Google Accelerator
(http://webaccelerator.google.com/). I'd also guess that a syntax-level
tag won't. Is this important?
The HTML solution for people who could not implement Expires: seems to
On 5/5/05, John Panzer [EMAIL PROTECTED] wrote:
I assume an HTTP Expires header for Atom content will work and play well
with caches such as the Google Accelerator
(http://webaccelerator.google.com/). I'd also guess that a syntax-level
tag won't. Is this important?
Yes, and yes. This is
Brett Lindsley wrote:
Andy, I recall bringing up the same issue with respect to portable
devices. My angle
was that firing up the transmitter, making a network connection and
connecting to
the server is still an expensive operation in time and power (for a
portable
device) - even if the server
In reviewing the protocol spec (and the basic protocol spec), there is
no mention
of recommended HTTP headers. There are examples in the basic protocol
spec that
shows ETag and Last-Modified but not Expires. Maybe there should be a
section
in the protocol spec showing recommended headers (a
Isn't this what the HTTP Expires header is for
(http://greenbytes.de/tech/webdav/rfc2616.html#header.expires)?
I don't think this helps a lot with my original issue because in many cases
a feed's updater will either not know when they will next update the feed,
or will be updating the feed
On 4 May 2005, at 9:10 am, Andy Henderson wrote:
I am adding Atom support to my Agg. For RSS feeds, I have used the
ttl and
sy:updatePeriod / sy:updateFrequency elements to allow feed
providers to
limit refresh rates.
Why?
I have, in any case, imposed a minimum refresh rate of one hour -
Andy Henderson wrote:
Isn't this what the HTTP Expires header is for
(http://greenbytes.de/tech/webdav/rfc2616.html#header.expires)?
I don't think this helps a lot with my original issue because in many cases
a feed's updater will either not know when they will next update the feed,
or will be
On 4 May 2005, at 11:44 am, Brett Lindsley wrote:
There is no reason to check feeds that are not being updated, but
then, there currently is no way to know this.
plug plug: http://www.fondantfancies.com/apps/shrook/distfaq.php
As you indicated, if the feed had some
element that indicated it
PaceCaching uses the HTTP model for Atom, whether Atom is used over HTTP
or some other protocol.
PaceCaching was rejected by the editors because it was too late (two months
ago) and non-core. I think that: a) it is never too late to get it right,
and b) scalability is core.
The PACE describes
On 5/4/05, Walter Underwood [EMAIL PROTECTED] wrote:
PaceCaching uses the HTTP model for Atom, whether Atom is used over HTTP
or some other protocol.
PaceCaching was rejected by the editors because it was too late (two months
ago) and non-core.
In this WG, the editors don't reject
On 5/5/05 12:44 AM, Graham [EMAIL PROTECTED] wrote:
uses 3GB a day, or about $1.20 at current prices.
only in some parts of the world.
over here I'm paying 13.2 cents per K and reading from a recent bill
2,982.61 Kbytes cost me $393.79 AUD.
e.
On May 4, 2005, at 7:44 AM, Graham wrote:
A quick look at that site turned up only one other site actually
complaining, MSDN, and they changed their minds:
Actually, as I recall, last time this came up (proposed by Walter
Underwood), someone pointed out accurately that RSS2 has had this
This is a myth perpetuated by cheapskate bloggers. There's no
technical reason for it beyond I bought a lousy hosting package.
Graham: I disagree. In a time where referrer and trackback spam agents
are hammering servers everywhere, it's quite reasonable for aggregator
developers to exhibit
On May 4, 2005, at 3:44 AM, Brett Lindsley wrote:
Andy, I recall bringing up the same issue with respect to portable
devices. My angle
was that firing up the transmitter, making a network connection and
connecting to
the server is still an expensive operation in time and power (for a
portable
On 4 May 2005, at 7:11 pm, Chris DeSalvo wrote:
My feed list amounts to about 20 MB of data per day when polling
once per hour. That is a lot of air time for a small radio, and a
lot time spent grinding in an XML parser for a small CPU. This is
especially upsetting because by my
On May 4, 2005, at 11:35 AM, Graham wrote:
On 4 May 2005, at 7:11 pm, Chris DeSalvo wrote:
My feed list amounts to about 20 MB of data per day when polling once
per hour. That is a lot of air time for a small radio, and a lot
time spent grinding in an XML parser for a small CPU. This is
I do not disagree. I just wanted to get my $0.02 in for completeness.
I'm happy as a clam with atom as it is now.
-chris
On May 4, 2005, at 12:52 PM, Robert Sayre wrote:
No one is denying the existence of the problem you're describing.
However, this WG has consistently decided is that an
On 5/4/05, Chris DeSalvo [EMAIL PROTECTED] wrote:
If the feed provided a hint for a reasonable polling frequency, it
would be a plus for limited-resource devices. I hate to suggest that
the format be changed as a prophylactic measure against bad-citizen
servers, but that is the problem
On 5/4/05, Roger B. [EMAIL PROTECTED] wrote:
That's not to say that there's something necessarily wrong with an
aggregator that allows users to pull feeds every five minutes. If
In the toy aggregator I wrote I played with a scheduler that tried to
throttle itself based on the feeds response.
Chris DeSalvo wrote:
As the author of an aggregator app for a portable wireless device I
can tell you that this is a serious problem for this class of products.
You didn't list support for RFC3229+feed[1,2] as one of the things
you are doing. This would help you drastically reduce the
34 matches
Mail list logo
