[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eXtensible Content Syndication (the next step for OCS)



I'm coming in a bit late for this. Sorry.

First, what are we looking to actually have in the feed list itself? One
person recently said that the feed list should contain nothing about the
content of the feed - only about it's location. The reasoning was that the
content of the feed shouldn't be replicated because the content creator
could change it at any time.

Personally, I agree with that only a tad bit. I think the reasoning is
sound - we shouldn't assume too much about the feed (like a never changing
title or description), but as a client creator, I also think it would be
stupid.

If someone downloads my client, and is provided with a list of 1000 feeds
with no titles or description, than that basically means I have to waste
the user's time as I go out and somehow aggregate the title and
descriptions into a database myself - no user is gonna want to wait 50
minutes while I get all the titles and description each time they want to
add a new channel (or each week, or what have you). They're not going to
understand or care, really, that the XML format is great and well defined.
They're just gonna care that it's taking a hella long time.

So, whether it's a standard or not, any solution I choose is gonna have the
title and description built into the channel list. Sadly enough, I'm going
to be steering the discussion more toward stranger burtonator than friend
Aaron Swartz. Burtonator's making a client, Aaron isn't.

>- - The format is too complex and it is hard to understand even for experts.

Agreed. Your solution makes me happy because it doesn't use attributes.
Primarily, 90% of RSS feeds don't use attributes either (and the attributes
that do exist can often be ignored) - therefore, a channel/feed listing
shouldn't contain them either.

>- - Doesn't support mime types.  XCS should support both mimeTypes (text/xml,

Why should we need these again? Just to give more information about the
feed on the other end and the format in which it's in? If that's the case,
then it's much like the title and description - something that the user
controls and can change at will.

Burtonator, I don't know how you handle feed updates or "is this feed still
publishing", but there are a few things that your proposal doesn't address:

 - Aliases. Jeff Barr has a large list of aliases for sites - duplicates
   of the content, only at different URLs. How would those be handled
   in the list? I worry that making an entire new <syndication> entry
   for each will bloat the list. Perhaps we could just add an <alias>?

 - Standard junky junk concerning internal usage of the channel in
   question. Perhaps the following optional module:

     <internal:added>Jun 12 1999 12:32:45 GMT</internal:added>
     <internal:filesize>3421</internal:filesize>
     <internal:error>404 File Not Found</internal:error>
     <internal:lastchecked>another ISO date</internal:lastchecked>
     <internal:lastupdated>another ISO date</internal:lastupdated>

   Roughly, "added" would suggest when the channel was first added
   to the list, allowing queries such as "show me all channels in the
   past month" or "show me channels within the past two days".

   "filesize" is there to circumvent servers that do NOT send
   last-modified headers with each request. The AmphetaDesk channel
   list offers 1600 "fresh" channels, even though there are probably
   a good 500 that had to be allowed in by default, since they
   didn't send a last-modified header (and I had to give them the
   benefit of the doubt). The "filesize" entry would allow us to
   check either the content-length header or calculate the file size
   ourselves as a secondary check against freshness.

   "error" contains any error response from the server.

   "lastchecked" is when we last touched the entry with positive
   news, ie title or description updates, or that the channel
   has been updated since last check. If there are any negative
   news (like server error, date/filesize the same), then the
   "lastchecked" won't be changed.

   "lastupdated" is a date of when the channel was last updated.
   usable only if the feed list is updated on a regular basis.

That's it for me this round. Concerning Aaron's followup message, I think
the dc:language should definitely be as close to required as possible, but
don't like his attribute loving format. I fear the "use RDF! use RDF!"
admonishing.

-- 
Morbus Iff ( i am your scary godmother )
http://www.disobey.com/ && http://www.gamegrene.com/
please me: http://www.amazon.com/exec/obidos/wishlist/25USVJDH68554
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus