James M Snell wrote:
Ok, question for the group.
Scenario: A content source is updated 100 times per hour. The Atom feed
currently only displays the 20 most recent entries. Users who are not
checking the feed every 10 minutes or so are missing entries. How do we
address this?
Antone Roundy wrote:
On Thursday, June 16, 2005, at 04:37 PM, James M Snell wrote:
Scenario: A content source is updated 100 times per hour. The Atom
feed currently only displays the 20 most recent entries. Users who
are not checking the feed every 10 minutes or so are missing entries.
The best solution is just to add a link types to the atom syntax: a
link to the previous feed document that points to the next bunch of
entries. IE. do what web sites do. If you can't find your answer on
the first page, go look at the next page.
How do you know when to stop? If the
Martin,
The general idea seems to be that conversion to HTML is good for
human consumption with a browser, and for human navigation in an
archive. message/rfc822 is the original, and may be very good for
reuse in a mailer (e.g. for replying), except that mailers don't
support it much at the
The plus side to the third option is that it is really no different than
an Atom feed that uses content payloads of any other arbitrary XML media
type (section 4.1.3.3 item #4). The current spec is silent on what an
Atom implementer needs to do with content media types that they don't
Uh, has Mark spotted a dumb bug here that we should fix? Do we care
if *remote* content is of a composite MIME type? My feeling was that
we ruled out composite types in *local* content, for fairly obvious
reasons. The fix is obvious, in 4.1.3.1
Failing that, it MUST be a MIME media
Appears that way. +1 to making composite types in remote content legal.
Another question while we're discussing this part of the spec (stemming
from the XML Enc discussion): currently there appears to be no language
about what should happen if an Atom processor encounters a content media
Henry Story wrote:
The best solution is just to add a link types to the atom syntax:
a link to the previous feed document that points to the next bunch of
entries. IE. do what web sites do. If you can't find your answer on
the first page, go look at the next page.
How do you know when to
* James M Snell [EMAIL PROTECTED] [2005-06-17 20:15]:
currently there appears to be no language about what should
happen if an Atom processor encounters a content media type
that it doesn't understand. Should it ignore the content? Does
it report an error? Should it try to process the
/ David Powell [EMAIL PROTECTED] was heard to say:
| a) Section 6.4 omits atom:source as a valid location for Metadata Extensions,
| but it is allowed by the RelaxNG in 4.2.11. I believe that the RelaxNG
| reflects our intent to allow extensions to be preserved in atom:source.
That seems
Well, what I'm going for more is an understanding of what should happen
during parsing. For example, in Section 5 we dictate that Atom
Processors MUST NOT reject an Atom Document containing ... a signature
because they are not capable of verifying it... the MOST I think could
be done in the
On Friday, June 17, 2005, at 12:32 PM, Bob Wyman wrote:
This is *not* simpler than taking a push feed using Atom over XMPP.
For a push feed, all you do is:
1. Open a socket
2. Send a login XML Stanza
3. Process the stanzas as they arrive.
...
For your
Antone Roundy wrote:
XMPP:
5. If the feed had entries that were old and not updated, go to step 7 6.
If the feed has a first or next or whatever link, go to step 1 using
that link 7. Open a socket 8. Send login XML stanza
I am assuming that if you are pushing entries via Atom over
Mark Baker wrote:
Martin,
The general idea seems to be that conversion to HTML is good for
human consumption with a browser, and for human navigation in an
archive. message/rfc822 is the original, and may be very good for
reuse in a mailer (e.g. for replying), except that mailers don't
On 6/17/05, Bob Wyman [EMAIL PROTECTED] wrote:
Let's keep Atom as it is now -- without the first and next tags
and encourage folk who need to keep up with high volume streams to use Atom
over XMPP.
-1
Let's keep Atom as it is now explain to folks who need to keep up with
high volume
Joe Gregorio wrote:
The one thing missing from the analysis is the overhead, and
practicality, of switching protocols (HTTP to XMPP).
I'm not aware of anything that might be called overhead. What our
clients do is, upon startup, connect to XMPP and request the list of Atom
files that
On 6/17/05, Bob Wyman [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
The one thing missing from the analysis is the overhead, and
practicality, of switching protocols (HTTP to XMPP).
I'm not aware of anything that might be called overhead.
I was referring to switching both the client
On 18/6/05 6:57 AM, Bob Wyman [EMAIL PROTECTED] wrote:
Let's keep Atom as it is now -- without the first and next tags
and encourage folk who need to keep up with high volume streams to use Atom
over XMPP. Lowered bandwidth utilization, reduced latency and simplicity are
good things.
how
On 18/6/05 7:42 AM, Thomas Broyer [EMAIL PROTECTED] wrote:
So what if I provide a src attribute but no type attribute?
The type attribute would default to text, but text is forbidden
if src is provided...
I suggest that if src is provided but not type, there is no type
value, as this
Joe Gregorio wrote:
On 6/17/05, Bob Wyman [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
The one thing missing from the analysis is the overhead, and
practicality, of switching protocols (HTTP to XMPP).
I'm not aware of anything that might be called overhead.
I was referring to
Sam asked
P.S. Why is this on atom-sytax? Is there a concrete proposal we are
talking about here? Is there likely to be?
I launched this discussion here for three reasons:
1. Everyone who care's about it is probably already here
2. Main discussion about the syntax is pretty much
That's what I believe Bob's RFC3229+Feed proposal addresses.
If I understand Bob's solution correctly, it goes something like:
1) wake up
2) scratch whatever you need to scratch
3) turn on computer, launch feed reader
4) feed reader does some RFC3229+feed magic to catch up on what happened
22 matches
Mail list logo
