Phil Ringnalda wrote:
Arve Bersvendsen wrote:
On Tue, 03 May 2005 18:52:59 +0200, Tim Bray [EMAIL PROTECTED] wrote:
http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt
1) Change the attribute value for the rel from alternate to feed,
Don't forget, since you would be doing that
On May 4, 2005, at 02:56, David Nesting wrote:
Plus, feed is kind of application-specific. What about related?
It's a spec for discovering *feeds*. It is proper to have an
app-specific rel value to avoid feed-specific apps downloading non-feed
related documents.
--
Henri Sivonen
[EMAIL
On Apr 29, 2005, at 12:17, Martin Duerst wrote:
Making this more precise is definitely desirable. But there is also
an i18n issue: This works fine for languages that use spaces between
words. It doesn't work for languages that don't have spaces between
words (Chinese, Japanese, Thai,...). If Text
On 4/5/05 3:52 PM, fantasai [EMAIL PROTECTED] wrote:
'feed' is not really defining a /relation/, it's defining a sort of
meta-content-type... But I would much prefer that to forcing 'alternate'
on non-'alternate' links.
instead of feed, consider updates, which gets closer to the gist of the
Randy Charles Morin wrote:
+1 to adding lang as an attribute to link
thanks Robert
link lang='en' ...
The HTML and XHTML specification already define that.
--
Anne van Kesteren
http://annevankesteren.nl/
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
On Tuesday, May 3, 2005, at 11:41 PM, fantasai wrote:
David Nesting wrote:
I expect that many of my implementations will utilize content
negotiation
(using the same URL as an HTML representation, where needed), so I
expect
that I'll have some links like:
link rel=alternate href=/
On 5/4/05, fantasai [EMAIL PROTECTED] wrote:
Who's to say we can't overload it a little for this case?
You are not writing the HTML 4.01 spec, you're writing an autodiscovery
spec that takes advantage of the syntax *and semantics* given in HTML 4.
Your specification should be consistent
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 5/4/05, Robert Sayre [EMAIL PROTECTED] wrote:
On 5/4/05, fantasai [EMAIL PROTECTED] wrote:
Who's to say we can't overload it a little for this case?
You are not writing the HTML 4.01 spec, you're writing an autodiscovery
spec that takes advantage of the syntax *and semantics*
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
Arve Bersvendsen wrote:
On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid
[EMAIL PROTECTED] wrote:
instead of feed, consider updates, which gets closer to the gist
of the sense
No. To me 'Updates' signifies that something is 'updated'. Even posting
new content falls outside of that
Robert Sayre wrote:
On 5/4/05, fantasai [EMAIL PROTECTED] wrote:
Who's to say we can't overload it a little for this case?
You are not writing the HTML 4.01 spec, you're writing an autodiscovery
spec that takes advantage of the syntax *and semantics* given in HTML 4.
Your specification should be
On 5/4/05, fantasai [EMAIL PROTECTED] wrote:
The definition of 'alternate' is not one line long on my screen, but
here's the first sentence of it:
# Alternate
# Designates substitute versions for the document in which the link
occurs.
--
On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote:
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation.
how is a feed of recent entries a substitute version for the document in
which the link occurs when that document is some
Robert Sayre wrote:
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation. It is not contradictory.
But a feed is not a substitute version of an archive page as most
archived entries are not in the feed anymore.
That said, I'm totally in
how is a feed of recent entries a substitute version for the document in
which the link occurs when that document is some blog post long since
dropped out of the feed?
Eric: A devil's advocacy moment... if I change the published date for
the document to today's date, it will suddenly spring
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
* Eric Scheid [EMAIL PROTECTED] [2005-05-05 02:35+1000]
On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote:
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation.
how is a feed of recent entries a substitute version for
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
Dan Brickley wrote:
* Eric Scheid [EMAIL PROTECTED] [2005-05-05 02:35+1000]
On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote:
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation.
how is a feed of recent entries a substitute
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
On May 4, 2005, at 11:02 AM, Robert Sayre wrote:
I think it would be a mistake to see this as an opportunity to invent
a supremely capable and expressive autodiscovery spec. I've seen
mozilla, safari, NNW do autodiscovery. I'm sure bots from PubSub,
Technorati, Yahoo, etc do it as well. We should
Antone Roundy wrote:
On Tuesday, May 3, 2005, at 11:41 PM, fantasai wrote:
David Nesting wrote:
I expect that many of my implementations will utilize content
negotiation
(using the same URL as an HTML representation, where needed), so I
expect
that I'll have some links like:
link
Antone Roundy wrote:
On Wednesday, May 4, 2005, at 12:59 PM, fantasai wrote:
Again, my friend's blog feed is not an Atom version of /my/ web page;
linking to it as alternate would be wrong.
To me, this raises a red flag, suggesting that using an autodiscovery
link from your web page to your
Antone Roundy wrote:
On Wednesday, May 4, 2005, at 12:59 PM, fantasai wrote:
Again, my friend's blog feed is not an Atom version of /my/ web page;
linking to it as alternate would be wrong.
To me, this raises a red flag, suggesting that using an autodiscovery
link from your web page to your
On 5/4/05, Robert Sayre [EMAIL PROTECTED] wrote:
Mark's draft does an excellent job of documenting that reality.
+1
-joe
--
Joe Gregoriohttp://bitworking.org
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
fantasai wrote:
Arve Bersvendsen wrote:
On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid
[EMAIL PROTECTED] wrote:
instead of feed, consider updates, which gets closer to the gist
of the sense
No. To me 'Updates' signifies that something is 'updated'. Even
posting new content falls
fantasai wrote:
Arve Bersvendsen wrote:
On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid
[EMAIL PROTECTED] wrote:
instead of feed, consider updates, which gets closer to the gist
of the sense
No. To me 'Updates' signifies that something is 'updated'. Even
posting new content falls
Eric Scheid wrote:
On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote:
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation.
how is a feed of recent entries a substitute version for the document in
which the link occurs
On Wednesday, May 4, 2005, at 04:49 PM, Nikolas 'Atrus' Coukouma wrote:
Eric Scheid wrote:
On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote:
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation.
how is a feed of recent entries a
On 5/5/05 4:02 AM, Thomas Broyer [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation. It is not contradictory.
But a feed is not a substitute version of an archive page as most
archived
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.
On 5/5/05 4:17 AM, Dan Brickley [EMAIL PROTECTED] wrote:
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation.
how is a feed of recent entries a substitute version for the document in
which the link occurs when that document is some
On 5/5/05 5:20 AM, Antone Roundy [EMAIL PROTECTED] wrote:
On Wednesday, May 4, 2005, at 12:59 PM, fantasai wrote:
Again, my friend's blog feed is not an Atom version of /my/ web page;
linking to it as alternate would be wrong.
To me, this raises a red flag, suggesting that using an
Eric Scheid wrote:
On 5/5/05 4:38 AM, Nikolas 'Atrus' Coukouma [EMAIL PROTECTED] wrote:
Do you have some example that's more generally applicable?
in practice, people will put a link to the feed from which this page, and
others like it, are likely to be found, into entry only pages.
We have published profiles for both license and nofollow:
http://developers.technorati.com/wiki/RelLicense
http://developers.technorati.com/wiki/RelNoFollow
feel free to use them...
On May 3, 2005, at 11:16 PM, Mark Pilgrim wrote:
On 5/4/05, Henri Sivonen [EMAIL PROTECTED] wrote
No you don't.
How about alternate be recommended for only true substitutes; a feed
for comments or pictures should not be labelled alternate, as it is
not a substitute. feed is appealing, but does fly in the face of
practice.
There are existing rel values that could apply to qualify other kinds
of feeds,
http://www.intertwingly.net/wiki/pie/PaceOriginalAttribute
On 5/3/05, Martin Duerst [EMAIL PROTECTED] wrote:
I'm not really happy with this.
I found Martin's comments (copied in full below) to be accurate. So, I
thought I would try another approach. Comments, suggestions, and
alterations are
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
+1 with a comment:
If this
Pace is accepted (and I hope it will be) the issue of Duplicate IDs should probably
be dealt with in Marks Implementation Guide.[1]
Atom
supports the publishing of newer versions of an entry which use the
same atom:id as earlier versions of the same entry.
On May 4, 2005, at 6:20 PM, Bob Wyman wrote:
+1 with a comment:
If this Pace is accepted (and I hope it will be) the issue of
Duplicate IDs should probably be dealt with in Marks Implementation
Guide.[1]
Er, I had planned to refine this a bit and then announce it to the
group with some
On 5/5/05 5:36 AM, fantasai [EMAIL PROTECTED] wrote:
- specify that UAs MAY also recognize the rel=alternate and
type=application/atom+xml combination as an autodiscoverable Atom
feed even if 'feed' is not among the rel values,
and that UA should check that the representation
co-chair-hat status=OFF
http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs
This Pace was motivated by a talk I had with Bob Wyman today about the
problems the synthofeed-generator community has.
Summary:
1. There are multiple plausible use-cases for feeds with duplicate IDs
2. Pro and
54 matches
Mail list logo
