Re: Polling Sucks! (was RE: Atom feed synchronization)

[James M Snell]

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 
during the night
5) feed reader opens a XMPP connection to receive the active stream of 
new entries


Eric Scheid wrote:


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 does Atom over XMPP help in this scenario:

1) wake up
2) scratch myself, stagger around in morning fog
3) turn on computer, launch feed reader
4) wonder what changes happened during the night

e.


 

Re: Polling Sucks! (was RE: Atom feed synchronization)

[James M Snell]

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 complete so there is 
no real risk of derailing anything


3. If there was no already accepted solution to the problem, this would 
be a logical place to begin hunting for and discussing the solution


That said, however, is there a better venue that you could suggest?

Capping out the conversation a bit, Bob Wyman's RFC3229+feed proposal, 
once written up into an Internet-Draft, will provide the solution that 
I'm searching for (e.g. the ability to catch up on what has changed in a 
feed over a given period of time).  The XMPP Push model would likely not 
be implemented in the case I'm considering but I couldn't rule it out 
completely.  I believe it is Bob's intention to draft up the 
RFC3229+feed and pitch it to this group for discussion.


Sam Ruby wrote:



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 switching both the client and server from running
HTTP to running XMPP. That may not be practical or even possible
for some people. Yes, I understand that you run this right now.
Yes, I understand that you run a business doing this right now.
Yes, I agree that your solution is one way to solve the problem.

Do you agree that 99.99% of all syndication is done via
HTTP today and also offering an HTTP based solution would be of value?



Joe, I'd be careful with how you structure this argument.  It could be 
applied in a different context, for example:


  Do you agree that 99.99% of all syndication is done via HTTP GET
  and POST today and offering a solution based only on these two
  verbs would be of value?

One can go down this path and cater to the least common denominator 
always, or one can say that perhaps MIDP 1.0 phones are not 
particularly well adapted to perform complex editing tasks beyond 
simple GET and POST.


Perhaps HTTP is suited to a wide, but not universal, range of 
applications dealing with relatively coarse and relatively 
infrequently updated content; and XMPP is well suited to a different 
-- always on, firehose -- set of applications, with a wide overlap 
between the two.


And perhaps they could be combined.  I could see a future where there 
was a "feedmesh" backbone with nodes exchanging data via XMPP, serving 
content out to the rest of the universe via HTTP.


- Sam Ruby

P.S.  Why is this on atom-sytax?  Is there a concrete proposal we are 
talking about here?  Is there likely to be?

Re: Polling Sucks! (was RE: Atom feed synchronization)

[Sam Ruby]

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 switching both the client and server from running
HTTP to running XMPP. That may not be practical or even possible
for some people. Yes, I understand that you run this right now.
Yes, I understand that you run a business doing this right now.
Yes, I agree that your solution is one way to solve the problem.

Do you agree that 99.99% of all syndication is done via
HTTP today and also offering an HTTP based solution would be of value?


Joe, I'd be careful with how you structure this argument.  It could be 
applied in a different context, for example:


  Do you agree that 99.99% of all syndication is done via HTTP GET
  and POST today and offering a solution based only on these two
  verbs would be of value?

One can go down this path and cater to the least common denominator 
always, or one can say that perhaps MIDP 1.0 phones are not particularly 
well adapted to perform complex editing tasks beyond simple GET and POST.


Perhaps HTTP is suited to a wide, but not universal, range of 
applications dealing with relatively coarse and relatively infrequently 
updated content; and XMPP is well suited to a different -- always on, 
firehose -- set of applications, with a wide overlap between the two.


And perhaps they could be combined.  I could see a future where there 
was a "feedmesh" backbone with nodes exchanging data via XMPP, serving 
content out to the rest of the universe via HTTP.


- Sam Ruby

P.S.  Why is this on atom-sytax?  Is there a concrete proposal we are 
talking about here?  Is there likely to be?

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

[Eric Scheid]

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 value is just advisory and not authoritative. However,
> if src is not provided (the content is local), processors must "behave
> as though it were present with a value of text".

+1

Re: Polling Sucks! (was RE: Atom feed synchronization)

[Eric Scheid]

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 does Atom over XMPP help in this scenario:

1) wake up
2) scratch myself, stagger around in morning fog
3) turn on computer, launch feed reader
4) wonder what changes happened during the night

e.

Re: Polling Sucks! (was RE: Atom feed synchronization)

[Joe Gregorio]

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 and server from running
HTTP to running XMPP. That may not be practical or even possible
for some people. Yes, I understand that you run this right now.
Yes, I understand that you run a business doing this right now.
Yes, I agree that your solution is one way to solve the problem.

Do you agree that 99.99% of all syndication is done via
HTTP today and also offering an HTTP based solution would be of value?

   -joe

-- 
Joe Gregoriohttp://bitworking.org

RE: Polling Sucks! (was RE: Atom feed synchronization)

[Bob Wyman]

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 they are monitoring. They then immediately fetch those files to
establish their start-of-session state. From that point on, they only listen
to XMPP since anything that would be written to the Atom files is also
written to XMPP. HTTP is only used on start-up. It's a pretty clean process.

> Let's keep Atom as it is now explain to folks who need to keep up with 
> high volume streams the two options they have, either streaming over
> XMPP or "next" links.
Where are these "next" links defined? I don't see them in the Atom
Internet Draft. The word "next" doesn't even appear in the ID... If they
aren't there, how can you call them "Atom as it is now"? I thought Henry
Story was proposing these as extensions.

bob wyman

Re: Polling Sucks! (was RE: Atom feed synchronization)

[Joe Gregorio]

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 streams the two options they have, either
streaming over XMPP or "next" links.

>  Lowered bandwidth utilization, reduced latency and simplicity are
> good things.

The one thing missing from the analysis is the overhead, and practicality,
of switching protocols (HTTP to XMPP).

   Thanks,
   -joe

-- 
Joe Gregoriohttp://bitworking.org

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

[Thomas Broyer]

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
support it much at the moment.

http://www.example.org/lists/list/archive/12345"/>
   



Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
says;

 On the atom:content element, the value of the "type" attribute MAY be
 one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
 media type, but MUST NOT be a composite type (see Section 4.2.6 of
 [MIMEREG]).  If the type attribute is not provided, Atom Processors
 MUST behave as though it were present with a value of "text".

where "composite type" is defined to be multipart/* and message/*.  If
the intent of that restriction was to avoid the whole non-XML
attachments issue, then it seems to have failed to account for the use
of the "src" attribute to include the data by reference rather than by
value.

I'm sorry that I didn't notice this earlier. 8-(
 



Er, and it seems there's another (related) problem:
In 4.1.3.1:
[
If the type attribute is not provided, Atom Processors MUST behave as 
though it were present with a value of "text".

]
Just below, in 4.1.3.2:
[
If the "src" attribute is present, the "type" attribute SHOULD be 
provided and MUST be a MIME media type [MIMEREG], rather than "text", 
"html", or "xhtml".

]

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 value is just advisory and not authoritative. However, 
if src is not provided (the content is local), processors must "behave 
as though it were present with a value of text".


--
Thomas Broyer

RE: Polling Sucks! (was RE: Atom feed synchronization)

[Bob Wyman]

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 XMPP,
you would only push new and updated entries. Thus, a client shouldn't need
to check for "old and not updated" entries. Also, I'm assuming that since
you are pushing entries, you wouldn't be inserting "first" or "next" links
that needed to be followed. The client would get all of its entries from the
XMPP stream.

> XMPP could achieve parity in getting feed changes that occurred while
> offline, at the expense of implementation complexity parity, by
> polling the feed once upon startup.
My assumption is that any well-built XMPP feed reader will, in fact,
also be able to read Atom files via HTTP. This is what we do at PubSub and
Gush does the same. I think Bill's app also does this. 
The original question dealt can, I think, be summarized as: "How
does one best keep up with a high-volume Atom publisher?" My point was that
the "first" and "next" links don't make things any easier. They just force
the client to do a great deal of work to discover what the server already
knows -- which entries have been updated. The "first" and "next" links
approach just makes the process of working with feed files more complex as
well as more bandwidth intensive. XMPP support is a much better solution for
keeping up with changes while connected.
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.

bob wyman

Re: Polling Sucks! (was RE: Atom feed synchronization)

[Antone Roundy]

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 solution, you need to:
1. Poll the feed to get a pointer to the "first link". (each poll
will cost you a TCP/IP connection).
2. If you got a new "first link" then go to step 5
3. Wait some period of time (the polling interval)
4. GoTo Step 1
5. Open a new TCP/IP socket to get the next link
6. Form and send an HTTP request for the next entry
7. Catch the response from the server
8. Parse the response to determine if its time stamp is something
you've already seen.
9. If you haven't seen the current entry before, then go to step 5
10. Go to step 1 to start over.


Not to get into a big argument (each method has its advantages 
depending on circumstances), but allow me to revise the above a little. 
 The following assumes applications that attempt to keep you up-to-date 
on changes to the feed that occurred while you were offline:


XMPP:
1. Open a socket
2. Request and get the feed
3. Parse the XML
4. Process the entries (Determine whether each is new/updated or 
not--if so, do the appropriate thing)

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
9. Wait for a stanza (sending keep-alive packets periodically), and 
when it arrives...

10. Parse the XML
11. Process it (Determine whether the entry is new/updated or not and 
do the appropriate thing)

12. Go to step 9

Polling:
1. Open a socket
2. Request and get the feed
3. Parse the XML
4. Process the entries (Determine whether the entry is new/updated or 
not and do the appropriate thing)

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. Wait some period of time
8. Go to step 1

The XMPP app will need to contain a superset of the polling app's code. 
My assessment of which method wins on various issues:


Latency: XMPP
Implementation complexity: Polling
Bandwidth consumption: XMPP
Resource consumption between polls or pushes: Polling
Getting all feed changes while online: XMPP if you're trying to archive 
the feed, otherwise no difference

Getting feed changes that occurred while offline: no difference



If we're not concerned about ensuring that we get all changes, the 
story is different:


XMPP:
1. Open a socket
2. Send "login" XML stanza
3. Wait for a stanza (sending keep-alive packets periodically), and 
when it arrives...

4. Parse the XML
5. Process it (Determine whether the entry is new/updated or not and do 
the appropriate thing)

6. Got to step 3

Polling:
1. Open a socket
2. Request and get the feed
3. Parse the XML
4. Process the entries (Determine whether the entry is new/updated or 
not and do the appropriate thing)

5. Wait some period of time
6. Go to step 1

My assessment:

Latency: XMPP
Implementation complexity: similar
Bandwidth consumption: XMPP
Resource consumption between polls or pushes: Polling
Getting all feed changes while online: XMPP
Getting feed changes that occurred while offline: Polling

XMPP could achieve parity in getting feed changes that occurred while 
offline, at the expense of implementation complexity parity, by polling 
the feed once upon startup.

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

[James M Snell]

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 core spec is a similar statement saying "Atom Processors 
MUST NOT reject an Atom Document containing a content media type that it 
doesn't understand".  Whatever else the processor does with it (e.g. 
ignore it, display a warning to the user, attempt to find an application 
to handle the content, etc) is up to the implementation.


A. Pagaltzis wrote:


* 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 content
somehow (e.g. defer to some external processor)? 
   



The spec is supposed to explain what the bits means, but not to
tell anyone what to do with them, so there’s nothing it can
really mandate here. Certainly it can’t usefully *enforce*
anything.

This might be something that the implementor’s guide should
contain recommendations for. But even then, I don’t think that
doing more than suggesting a few best practices for a handful
of situations is feasible.

I expect that many newsreaders will simply ignore things they
don’t understand.

Personally, in the aggregator I occasionally work on, I plan to
pass the data to a whatever application the user’s mailcap says
is responsible for it. (I suppose you’d use the registry in
Windows; I don’t know what mechanism OS X provides.)

On the other hand, many scenarios will (hopefully!) involve Atom
feeds intended solely for consumption by machines rather humans.
I imagine that in at least a few of those, unexpected content
types should set off alarms.

So I don’t think there is any one course of action that we can
recommend for everyone; let alone mandate, if such a thing even
was in the scope of the spec. The best we could do is to
informally suggest certain practices for certain situations. (I’d
like to see desktop aggregators widely support what I am planning
to do with mine, f.ex; then putting stuff other than HTML in
feeds would have a chance to catch on.) And that too is probably
something the guide should do, not the spec.

Regards,
 

Re: Review of Section 6

[Norman Walsh]

/ 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 reasonable to me. I'd be content if we decided this was a
spec bug and agreed to add 'atom:source' to the lext of Metadata
Elements in Section 6.4.

| b) Section 6.4.1 and Section 6.4.2 don't place any restrictions on what 
elements
| may be used as Metadata Extensions, but the RelaxNG grammar explicitly 
excludes
| elements in the Atom namespace.  The Atom namespace should be reserved for
| future forwards-compatable revisions of Atom.

Given that our spec defines what the atom: elments mean and where they
can appear, it would seem bizarre to me to say that in Metadata
Extensions, any atom: element can be used for any purpose.

I conclude that the RELAX NG grammar reflects the groups intent in
these areas, but I'll change it if consensus proves me wrong. :-)

Be seeing you,
  norm

-- 
Norman Walsh <[EMAIL PROTECTED]> | The worst enemy of life, freedom and
http://nwalsh.com/| the common decencies is total anarchy;
  | their second worst enemy is total
  | efficiency.--Aldous Huxley


pgpNFMA7IO5Jt.pgp
Description: PGP signature

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

[A. Pagaltzis]

* 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 content
> somehow (e.g. defer to some external processor)? 

The spec is supposed to explain what the bits means, but not to
tell anyone what to do with them, so there’s nothing it can
really mandate here. Certainly it can’t usefully *enforce*
anything.

This might be something that the implementor’s guide should
contain recommendations for. But even then, I don’t think that
doing more than suggesting a few best practices for a handful
of situations is feasible.

I expect that many newsreaders will simply ignore things they
don’t understand.

Personally, in the aggregator I occasionally work on, I plan to
pass the data to a whatever application the user’s mailcap says
is responsible for it. (I suppose you’d use the registry in
Windows; I don’t know what mechanism OS X provides.)

On the other hand, many scenarios will (hopefully!) involve Atom
feeds intended solely for consumption by machines rather humans.
I imagine that in at least a few of those, unexpected content
types should set off alarms.

So I don’t think there is any one course of action that we can
recommend for everyone; let alone mandate, if such a thing even
was in the scope of the spec. The best we could do is to
informally suggest certain practices for certain situations. (I’d
like to see desktop aggregators widely support what I am planning
to do with mine, f.ex; then putting stuff other than HTML in
feeds would have a chance to catch on.) And that too is probably
something the guide should do, not the spec.

Regards,
-- 
Aristotle Pagaltzis // 

Polling Sucks! (was RE: Atom feed synchronization)

[Bob Wyman]

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 stop? If the pages are ordered  
> chronologically, the client will know to stop when he has come to a page
> with entries with update times before the date he last looked.

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 solution, you need to:
1. Poll the feed to get a pointer to the "first link". (each poll
will cost you a TCP/IP connection).
2. If you got a new "first link" then go to step 5
3. Wait some period of time (the polling interval)
4. GoTo Step 1
5. Open a new TCP/IP socket to get the next link
6. Form and send an HTTP request for the next entry
7. Catch the response from the server
8. Parse the response to determine if its time stamp is something
you've already seen.
9. If you haven't seen the current entry before, then go to step 5
10. Go to step 1 to start over.
(Note: I've eliminated and compressed a few steps to avoid more
typing... An actual implementation would be more complex than I describe
above.)

Your solution is more complex and generates much more network
traffic (i.e. because of polling the feed, repeatedly opening new TCP/IP
connections with all the traditional "slow start" overhead, and requesting
each "next link"). Additionally, you end up with reduced latency since the
age of any entry you discover will be, on average, half that of your polling
frequency plus some latency introduced by link following. (Yes, you could
rely on continuous connections and thus remove the overhead of creating so
many TCP/IP connections, however, at that point, you might as well have a
continuous push socket open...)
The push solution conserves network bandwidth, delivers data with
much less latency and is simpler to implement. 
Polling sucks! (that was a pun...)

bob wyman

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

[Sam Ruby]

Tim Bray wrote:


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 type.  If the "src" attribute  is 
not provided, i.e. the content is local, the value of the "type"  
attribute MUST NOT be a composite type... "


I have no objection, but I will point out that for the forseeable future 
the number of tools that are likely to support this is likely to be 
vanishingly small.


- Sam Ruby


-Tim

On Jun 17, 2005, at 7:05 AM, Mark Baker wrote:


http://www.example.org/lists/list/archive/12345"/>



Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
says;

  On the atom:content element, the value of the "type" attribute  MAY be
  one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
  media type, but MUST NOT be a composite type (see Section 4.2.6 of
  [MIMEREG]).  If the type attribute is not provided, Atom Processors
  MUST behave as though it were present with a value of "text".

where "composite type" is defined to be multipart/* and message/*.  If
the intent of that restriction was to avoid the whole non-XML
attachments issue, then it seems to have failed to account for the use
of the "src" attribute to include the data by reference rather than by
value.

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

[Eric Scheid]

On 18/6/05 3:14 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:

> 
> 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 type.  If the "src" attribute
> is not provided, i.e. the content is local, the value of the "type"
> attribute MUST NOT be a composite type... "

+1

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

[James M Snell]

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 
type that it doesn't understand.  Should it ignore the content? Does it 
report an error?  Should it try to process the content somehow (e.g. 
defer to some external processor)? 


Tim Bray wrote:



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 type.  If the "src" attribute  
is not provided, i.e. the content is local, the value of the "type"  
attribute MUST NOT be a composite type... "


-Tim

On Jun 17, 2005, at 7:05 AM, Mark Baker wrote:


http://www.example.org/lists/list/archive/12345"/>



Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
says;

  On the atom:content element, the value of the "type" attribute  MAY be
  one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
  media type, but MUST NOT be a composite type (see Section 4.2.6 of
  [MIMEREG]).  If the type attribute is not provided, Atom Processors
  MUST behave as though it were present with a value of "text".

where "composite type" is defined to be multipart/* and message/*.  If
the intent of that restriction was to avoid the whole non-XML
attachments issue, then it seems to have failed to account for the use
of the "src" attribute to include the data by reference rather than by
value.

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

[Tim Bray]

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 type.  If the "src" attribute  
is not provided, i.e. the content is local, the value of the "type"  
attribute MUST NOT be a composite type... "


-Tim

On Jun 17, 2005, at 7:05 AM, Mark Baker wrote:


http://www.example.org/lists/list/archive/12345"/>


Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
says;

  On the atom:content element, the value of the "type" attribute  
MAY be

  one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
  media type, but MUST NOT be a composite type (see Section 4.2.6 of
  [MIMEREG]).  If the type attribute is not provided, Atom Processors
  MUST behave as though it were present with a value of "text".

where "composite type" is defined to be multipart/* and message/*.  If
the intent of that restriction was to avoid the whole non-XML
attachments issue, then it seems to have failed to account for the use
of the "src" attribute to include the data by reference rather than by
value.

Re: More on Atom XML signatures and encryption

[James M Snell]

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 
understand.


Paul Hoffman wrote:



At 2:25 PM -0700 6/16/05, James M Snell wrote:


So perhaps we should limit XML encryption to

   a) The entire feed
   b) individual entries and
   c) the content of content elements. (examples 2, 4 and 5 in my 
original note).



Or less. Sections 5.1 and 5.2 of the current spec clearly only cover 1 
and 2. Going beneath that is outside the spec, and likely to be 
ignored by implementers.


--Paul Hoffman, Director
--Internet Mail Consortium

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

[Mark Baker]

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 moment.
> 
>  src="http://www.example.org/lists/list/archive/12345"/>

Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
says;

  On the atom:content element, the value of the "type" attribute MAY be
  one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
  media type, but MUST NOT be a composite type (see Section 4.2.6 of
  [MIMEREG]).  If the type attribute is not provided, Atom Processors
  MUST behave as though it were present with a value of "text".

where "composite type" is defined to be multipart/* and message/*.  If
the intent of that restriction was to avoid the whole non-XML
attachments issue, then it seems to have failed to account for the use
of the "src" attribute to include the data by reference rather than by
value.

I'm sorry that I didn't notice this earlier. 8-(

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.  http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Re: Atom feed synchronization

[Henry Story]

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 pages are ordered  
chronologically, the client will know to stop
when he has come to a page with entries with update times before the  
date he last looked.


This is:

- simple,
- easy to see (no need to look at invisible header fields),
- easy to understand (no need to read another complicated rfc  
document)

- easy to implement (well it so simple)
- low tech (you don't need anything more than a server  
supporting http)



Henry


On 17 Jun 2005, at 00:37, 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?


Solution: Rather than using a feed with a fixed number of entries,  
provide a mechanism that allows users to specify the last time they  
retrieved the feed and have the feed return all entries added since  
that time.


Question: What is the best way to provide that mechanism:  
querystring parameter or HTTP header or some other way I'm not  
thinking of


   http://...?last-retrieved=12345

OR

  GET ... HTTP/1.1
  Host: ...
  Last-Retrieved: 12345

- James

Re: Atom feed synchronization

[Bill de hÓra]

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.  
How do we address this?



1) Tell users to poll more frequently--if they don't, that's their problem


Doesn't solve the problem, probably makes things worse.



2) Make the feed longer than 20 entries


Same as 1)

2a) If the feed is SOMETIMES updated 100 times per hour, but sometimes 
only twice per hour, dynamically set the feed length--when regenerating 
the feed, include all entries updated in the last hour or so, down to 
some minimum number


Same as 2)


3) Push instead of pull


This works.

4) Create a new link @rel to point to the next X entries and keep a 
series of static documents containing the older entries


Might work, but requires at least as much extra mechanism as a query param.


cheers
Bill

Re: Atom feed synchronization

[Bill de hÓra]

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?


Solution: Rather than using a feed with a fixed number of entries, 
provide a mechanism that allows users to specify the last time they 
retrieved the feed and have the feed return all entries added since that 
time.


Question: What is the best way to provide that mechanism: querystring 
parameter or HTTP header or some other way I'm not thinking of


   http://...?last-retrieved=12345

OR

  GET ... HTTP/1.1
  Host: ...
  Last-Retrieved: 12345



We found shared time imprecise enough, and other workarounds over HTTP 
complex enough, that to solve this problem (must get all entires) we 
pushed the feed out using XMPP. All the technical problems I saw then 
came down to inconsistent rates of change. The simplest answer was to 
get rid of HTTP and use XMPP.


cheers
Bill

Re: feed or entry

[A. Pagaltzis]

* Dave Pawson <[EMAIL PROTECTED]> [2005-06-16 22:05]:
> Process. I write an instance. document element is a:feed.
> 
> Each successive day (or thereabouts) I write an entry. I'm
> processing via XSLT.
> 
> I don't want a single monolith of a file, so I'm writing daily
> using a document element of a:entry.
> 
> The end product is an 'empty' a:feed element (i.e. no entry
> children) and 101 orphan a:entry instances, each with a days
> content.

I’m not sure I understand what you’re talking about, but would it
be a possibility to use the XPath document() function to slurp
the atom:entry documents into the atom:feed document using a
stylesheet? This is how my own blog works.

Regards,
-- 
Aristotle Pagaltzis //