Dave Johnson wrote:
On 6/5/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
i am on board with the idea behind #4, which is that each weblog should
have the ability to control what feeds it offers, but i don't
particularly see how the feedspec thingy is useful.

i have a couple more fundamental questions about what direction we
really want to take here, then a suggestion ...

1. Do we want to allow admins/users to have full control over what feeds
are available for a weblog?  or do we want to continue our current path
where we basically handle feeds for them?

We still want to handle feeds for most users. I think that is still an
important feature. But for some weblogs (and especially the frontpage
one) we want to allow a blog owner to add new category, language
and/or planet group filtered feeds.

I agree with this, but here's a couple follow up questions ...

1a. Do we want users to be able to override built-in feeds? For example, a weblog is already given an rss and atom feed, so should users be able to modify/alter how those feeds work? Or are we saying that those feeds are protected and standardized, so users can't hack them.

1b. Do we expect that any user should want to override a standardized feed like the weblog rss and atom feeds? Or should we enforce that those feeds be standard and alterations need to be done via a new feed?




2. Is it important for all feeds to be under the new
<weblog>/feed/<flavor> url?  or is it okay if custom feeds exist as
custom weblog pages under <weblog>/page/<myfeed>

I think each blog should have two primary feeds that exist in a
standard location: one for most recent entries and one for most
recent comments. For both feeds, individual bloggers should be
able to specify "full-content" or "excerpts". And both feeds should
accept a categrory argument.

I agree with that, but it doesn't fully answer the question. Do we want users to have the ability to add a new user-defined feed under the feeds section? Or do we want to control that section ourselves and make the site wide and planet feeds still standardized?

My feeling is that it's easier to keep things standardized, but long term we probably want to provide the flexibility for users to define their own feeds.




3. Do we want the site wide feed to be the default?  or should Roller
admins have to enable it when they want it?

I think each Roller site should also have two primary feeds that
exist in a standard location: one for most recent entries and one
for most recent comments. For both feeds, a global admin should
be able to: 1) turn the feed on or off and 2) specify "full-content" or
"excerpts". A category parameter should work here too.

I agree with all of that, except for maybe the category part, but that's not a big deal. In any case, I take it you are saying that you believe there should be site wide feeds for entries and comments and they should exist in a location separate from any existing weblog feeds.

I agree with that as well.




4. Should the rss/atom feed for the main blog only pertain to that
weblog?  or should it possibly pertain to a different set of data, like
the site wide feed or planet feed?  if it always pertains to the weblog
then other feeds need their own url path <weblog>/feed/<something>

That is the question I'm trying to answer. My current thinking is that
every blog should have those two standard feeds, but bloggers should
be free to define additional feeds.

I think that is a good way to handle it. So additional feeds like the site wide, planet, etc feeds would have their own locations.




suggestions ...

technically, as far as our rendering is concerned, there is no
difference between a weblog page and a weblog feed.  both are just
content to be rendered from a template.  the only difference right now
is that we don't let users manage their feed templates, instead we do
that for them.

That's not entirely true. For newsfeeds we can determine the
last-modified date by using the timestamp of the most recent entry.
For weblog pages, we have to use website.lastModified which is
more of a blunt instrument.

true, but the rendering part is still exactly the same. it's just ... model(s) + template = output




if we really want to give users truly flexible control over their feeds
then i suggest we simply move the feeds to become weblog templates just
like pages are now.  to make this happen i think all we would really
need to do is add 2 fields to the weblogpage table ...

* content type - to allow users to specify if the feed is rss, atom, etc. * page type - to specify if the template represents a "feed" or a "page".

we then make use of the existing "link" attribute of a weblog template
to complete the picture.  this way when an incoming request for
<weblog>/feed/foo comes in we simply lookup a template named "foo" with
a page type of "feed" and render that template.  these templates would
be editable as part of normal template editing interface, and we could
also lock down certain feeds that we prefer people not edit, like atom
and rss.

I like that and I think it will work much better than any feedspec string
or UI that we can come up with -- and it doesn't preclude someday
putting a feed builder UI in place.

Correct. A feed builder UI will practically be required actually. We can certainly get away without one, but it makes things much nicer.




then when someone wants to add a new feed, like the site wide feed or
planet feed, they just define a new template of type "feed", give it a
link value that they want and define the contents however they want it
to be rendered.

one thing to consider though is if this is really a good idea?  is this
really something that is desired from an enterprise blogging solution?
this would be quite a bit of change just to support a site wide feed.  a
lot of this sounds nice to me, but i'm not sure it's really needed.

Such flexibility is defintely needed for the frontpage blog and you've
described a good way of implementing it -- why not make it available to
all blogs? Bloggers  already have the ability to define new feeds via
templates, this just formalizes the process and puts feeds in a
standard place in the URL scheme.

I agree, I like flexibility. This does fairly sizeably expand the scope of the Atlas proposal, that's why I wanted to make sure we want to go down this path right now.

I have another idea which could also work together (or separate) from the approach I layed out above ...

Rather than trying to mesh the site and planet content directly into the existing standard weblog url scheme, maybe it would be useful to standardize some additions to the weblog url scheme for these components. Basically, add a new component to the url to specify site or planet content ...

<weblog>/site
<weblog>/site/feed/rss
<weblog>/site/feed/atom
<weblog>/site/feed/comments
<weblog>/planet
<weblog>/planet/group/<planetgroup>
<weblog>/planet/feed/rss?group=<planetgroup>
<weblog>/planet/feed/atom?group=<planetgroup>

I think there are some good and bad things about this approach ...

1. (+) It allows a weblog to be extended with Site and Planet functionality, but still function completely as a normal weblog if desired. The new functionality is only added on.

2. (+) It more easily allows us to standardize the location of things like the site wide content and planet content.

3. (+) Technically we don't have to make all the changes I originally mentioned to provide this functionality, but i think this approach would still benefit from my original suggestion.

4. (+) It lessens the burden on users to setup and manage custom content for site wide and planet content. technically we can still offer all the site wide and planet feeds without the user doing any configuration at all.

5. (-) It adds more stuff to the url structure.

My feeling is that it's definitely nice to have the site wide stuff be an addon to a weblog and have it not conflict with any of the normal weblog features and this idea definitely helps accomplish that. What do others think?

-- Allen



Anybody else want to comment? I'd like to attempt to write these
ideas up in the Atlas proposal.

- Dave

Reply via email to