Up to this point, the vast majority of use cases for Atom feeds is the
traditional syndicated content case. A bunch of content updates that
are designed to be distributed and aggregated within Feed readers or
online aggregators, etc. But with Atom providing a much more flexible
content
Am 25.08.2005 um 00:07 schrieb Mark Nottingham:
Just bouncing an idea around; it seems that there's a fair amount of
confusion / fuzziness caused by the term 'stateful'. Would people
prefer the term 'incremental'?
I.e., instead of a stateful feed, it would be an incremental feed;
On 24/08/2005 23:07, Mark Nottingham wrote:
Just bouncing an idea around; it seems that there's a fair amount of
confusion / fuzziness caused by the term 'stateful'. Would people
prefer the term 'incremental'?
I.e., instead of a stateful feed, it would be an incremental feed;
On Wed, Aug 24, 2005 at 11:25:12PM -0700, James M Snell wrote:
For example, suppose I build an application that depends on an Atom feed
containing binary content (e.g. a software update feed). I don't really
want aggregators pulling and indexing that feed and attempting to
display it
* James M Snell [EMAIL PROTECTED] [2005-08-25 08:35]:
I don't really want aggregators pulling and indexing that feed
and attempting to display it within a traditional feed reader.
Why, though?
There’s no reason aggregators couldn’t at some point become more
capable of doing something useful
On 8/25/05, James M Snell [EMAIL PROTECTED] wrote:
Up to this point, the vast majority of use cases for Atom feeds is the
traditional syndicated content case. A bunch of content updates that
are designed to be distributed and aggregated within Feed readers or
online aggregators, etc. But
A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2005-08-25 08:35]:
I don't really want aggregators pulling and indexing that feed
and attempting to display it within a traditional feed reader.
Why, though?
There’s no reason aggregators couldn’t at some point become more
James M Snell wrote:
Does the following work?
feed
...
x:aggregateno/x:aggregate
/feed
I think it is important to recognize that there are at least two
kinds of aggregator. The most common is the desktop end-point aggregator
that consumes feeds from various sources and then
On 25 Aug 2005, at 15:45, Joe Gregorio wrote:
On 8/25/05, James M Snell [EMAIL PROTECTED] wrote:
Up to this point, the vast majority of use cases for Atom feeds is
the
traditional syndicated content case. A bunch of content updates that
are designed to be distributed and aggregated
* Henry Story [EMAIL PROTECTED] [2005-08-25 16:55]:
Do we put base64 encoded stuff in html? No: that is why there
are things like
img src=...
img
src=data:image/gif;base64,R0lGODlhAQABAIAAAP///yH5BAEKAAEALAABAAEAAAICTAEAOw==
/
:-)
Regards,
--
Aristotle Pagaltzis //
A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2005-08-25 16:20]:
I dunno, I'm just kinda scratching my head on this wondering if
there is any actual need here. My instincts are telling me no,
but...
Seems to me that your instincts are right. :-)
I’m not sure why, in the
On Wednesday, August 24, 2005, at 04:07 PM, Mark Nottingham wrote:
Just bouncing an idea around; it seems that there's a fair amount of
confusion / fuzziness caused by the term 'stateful'. Would people
prefer the term 'incremental'?
I.e., instead of a stateful feed, it would be an
On Thursday, August 25, 2005, at 12:25 AM, James M Snell wrote:
Up to this point, the vast majority of use cases for Atom feeds is the
traditional syndicated content case. A bunch of content updates that
are designed to be distributed and aggregated within Feed readers or
online
On 25/08/2005, at 3:00 AM, Stefan Eissing wrote:
Am 25.08.2005 um 00:07 schrieb Mark Nottingham:
Just bouncing an idea around; it seems that there's a fair amount
of confusion / fuzziness caused by the term 'stateful'. Would
people prefer the term 'incremental'?
I.e., instead of a
Just brainstorming... (hey, I already threw out one harebrained idea
this week, what's one more?)
Perhaps something as simple as a single empty element (like fh:archive)
that describes the general behavior of the feed.
e.g. sliding / or snapshot /
feed
fh:sliding /!-- indicates
On Thursday, August 25, 2005, at 08:16 AM, James M Snell wrote:
Good points but it's more than just the handling of human-readable
content. That's one use case but there are others. Consider, for
example, if I was producing a feed that contained javascript and CSS
styles that would
On 25 Aug 2005, at 17:06, A. Pagaltzis wrote:
* Henry Story [EMAIL PROTECTED] [2005-08-25 16:55]:
Do we put base64 encoded stuff in html? No: that is why there
are things like
img src=...
img src=data:image/gif;base64,R0lGODlhAQABAIAAAP///
yH5BAEKAAEALAABAAEAAAICTAEAOw== /
At 10:22 AM -0400 8/25/05, Bob Wyman wrote:
James M Snell wrote:
Does the following work?
feed
...
x:aggregateno/x:aggregate
/feed
I think it is important to recognize that there are at least two
kinds of aggregator. The most common is the desktop end-point aggregator
that
* Henry Story [EMAIL PROTECTED] [2005-08-25 18:40]:
And it does not give me anything very intersting when I look at
it in either Safari or Firefox.
Of course not – it’s the infamous transparent single-pixel GIF.
:-)
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
It works in both Safari and Firefox; it's just that that particular
data: URI is a 1x1 blank gif ;)
On 25/08/2005, at 9:37 AM, Henry Story wrote:
On 25 Aug 2005, at 17:06, A. Pagaltzis wrote:
* Henry Story [EMAIL PROTECTED] [2005-08-25 16:55]:
Do we put base64 encoded stuff in
I can see reasonable uses for this, like marking a feed of local disk
errors
as not of general interest.
This is not published data - http://www.spacekdet.com/pipe/
Security by obscurity^H^H^H^H^H^H^H^H^H saying please -
http://www-cs-faculty.stanford.edu/~knuth/ (see the second link from
Le 05-08-25 à 06:44, James Aylett a écrit :
I like the use case, but I don't see why you would want to disallow
aggregators to pull the feed.
You might want it for many reasons. One of my reasons which worries
me more and more, is that some aggregators, bots do not respect the
Creative
Le 05-08-25 à 12:51, Walter Underwood a écrit :
/robots.txt is one approach. Wouldn't hurt to have a recommendation
for whether Atom clients honor that.
Not many honor it.
A while ago I had this list from http://varchars.com/blog/node/view/59
The Good
BlogPulse
NITLE Blog Spider
Karl Dubost wrote:
One of my reasons which worries me more and more, is that some
aggregators, bots do not respect the Creative Common license (or
at least the way I understand it).
Your understanding of Creative Commons is apparently a bit
non-optimal -- even though many people seem
Bob,
Thanks for the explanation. Much appreciated.
Le 05-08-25 à 15:59, Bob Wyman a écrit :
Karl Dubost wrote:
One of my reasons which worries me more and more, is that some
aggregators, bots do not respect the Creative Common license (or
at least the way I understand it).
It is
Bob Wyman wrote:
Karl Dubost wrote:
One of my reasons which worries me more and more, is that some
aggregators, bots do not respect the Creative Common license (or
at least the way I understand it).
Your understanding of Creative Commons is apparently a bit
non-optimal --
Mhh. I have not looked into this. But is not every desktop aggregator
a robot?
Henry
On 25 Aug 2005, at 22:18, James M Snell wrote:
At the very least, aggregators should respect robots.txt. Doing so
would allow publishers to restrict who is allowed to pull their feed.
- James
--On August 25, 2005 3:43:03 PM -0400 Karl Dubost [EMAIL PROTECTED] wrote:
Le 05-08-25 à 12:51, Walter Underwood a écrit :
/robots.txt is one approach. Wouldn't hurt to have a recommendation
for whether Atom clients honor that.
Not many honor it.
I'm not surprised. There seems to be a new
I would call desktop clients clients not robots. The distinction is
how they add feeds to the polling list. Clients add them because of
human decisions. Robots discover them mechanically and add them.
So, clients should act like browsers, and ignore robots.txt.
Robots.txt is not very widely
Mhh. I have not looked into this. But is not every desktop aggregator
a robot?
Henry: Depends on who you ask. (See the Newsmonster debates from a
couple years ago.)
Right now, I obey all wildcard and/or my-user-agent-specific
directives I find in robots.txt. If I were writing a desktop app, I
Walter Underwood wrote:
--On August 25, 2005 3:43:03 PM -0400 Karl Dubost [EMAIL PROTECTED] wrote:
Le 05-08-25 à 12:51, Walter Underwood a écrit :
/robots.txt is one approach. Wouldn't hurt to have a recommendation
for whether Atom clients honor that.
Not many honor it.
Yes, I see how one is meant to look at it. But I can imagine desktop
aggregators
becoming more independent when searching for information... Perhaps
at that point
they should start reading robots.txt...
Henry
On 25 Aug 2005, at 23:12, Walter Underwood wrote:
I would call desktop
On Thursday, August 25, 2005, at 03:12 PM, Walter Underwood wrote:
I would call desktop clients clients not robots. The distinction is
how they add feeds to the polling list. Clients add them because of
human decisions. Robots discover them mechanically and add them.
So, clients should act
Antone Roundy wrote:
How could this all be related to aggregators that accept feed URL
submissions?
My impression has always been that robots.txt was intended to stop
robots that crawl a site (i.e. they read one page, extract the URLs from it
and then read those pages). I don't believe
Bob: It's one thing to ignore a wildcard rule in robots.txt. I don't
think its a good idea, but I can at least see a valid argument for it.
However, if I put something like:
User-agent: PubSub
Disallow: /
...in my robots.txt and you ignore it, then you very much belong on
the Bad List.
--
35 matches
Mail list logo
