[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