I was thinking about this a little bit more on the way home and I have
one important question which I believe is important to answer before we
can figure out the implementation ..
Do we want to force the weblog selected as the frontpage blog to decide
if it will function as a site-wide aggregation blog or an individual
blog? Or another way to put it, are we going to allow the frontpage
blog function both as an individual weblog and the site-wide weblog or
does it have to choose one or the other?
IMO we *should* force the frontpage blog to decide if it will function
as a site-wide aggregation blog *or* as an individual blog, but it can't
be both. Here's my reasoning ...
I can only think of 4 possible ways in which Roller and the frontpage
could theoretically be configured ...
1. Hosting a single individual weblog. no need for site-wide functions.
2. Hosting multiple weblogs, but the homepage is supposed to show just
one of the weblogs. the users don't want any site-wide aggregation
functions.
3. Hosting multiple weblogs and the homepage should be a special weblog
which shows site-wide data and has site-wide feeds. The homepage blog
doesn't function as a blog on its own.
4. Hosting multiple weblogs and the homepage should be a special weblog
which shows site-wide data and has site-wide feeds. The homepage blogs
*should* function as a blog on its own.
IMO #1, #2, and #3 are all very valid scenerios which we certainly want
to support, but #4 is not. First off, I don't see a situation where
scenerio #4 is really of any benefit, it's almost certainly better if
weblog content is published outside of the homepage blog. Second, I'm
not sure that technically we have a good way to achieve #4. To
accomplish that *all* of the urls for site-wide content have to be
separate from normal weblog urls, and I don't think that is desirable.
Finally, I think that we greatly reduce the complexity of this problem
by not supporting option #4.
So at this point I would recommend that we only support options #1, #2,
and #3 and we do that using a combination of 2 properties. 1)
site.mainpageblog which identifies which blog serves as the homepage of
the application. 2) site.mainpageisaggregation (or similar) which
identifies if the homepage blog is serving as an aggregation blog or as
a standard weblog. This would allow us to configure the homepage blog
to work under all 3 options.
Also remember, if the homepage blog is functioning as an aggregation
blog then all of it's normal pages and feeds return site-wide content.
That means that the standard rss, atom, comment, etc feeds are all
site-wide versions from their normal urls.
Also note that this decision only applies to the one weblog chosen to
represent the mainpage blog. Other weblogs may be given the
SitePageModel and can use it however they see fit, but their feeds and
pages won't be the site-wide versions.
does that make sense? do we think that will work for providing the
site-wide content? thoughts?
-- Allen
Allen Gilliland wrote:
Dave Johnson wrote:
On 6/6/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
<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.
We can do that without all of the URLs you listed.
5. (-) It adds more stuff to the url structure.
That's the part that I really don't like.
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?
Think this URL scheme goes a little too far. I don't think we need to
give special treatment to site and planet pages. I think this is all
we need:
<weblog>/feed - Atom or RSS feed of weblog
<weblog>/feed/comments - Atom or RSS feed of weblog comments
<weblog>/feed/<feed-page-name> - Other type of feed
That's enough to allow each blog to create custom feeds and for blogs
with access to the Site and Planet page models, we can create
site/planet wide feeds.
I am totally fine with that approach, but we still need a way for users
to define their own feeds then, and that's the tricky part. The other
thing that's somewhat strange is that all we really need to do for the
site feed is to provide a url, since technically the FeedServlet is
already capable of delivering site-wide feeds.
I guess I am still very uncertain about how we plan to allow users to
make custom feeds, so I'd like to hear more about what we planning to do.
-- Allen
- Dave
