Comments below...
On 9/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I think the proposal looks good. Only 2 things I would comment on ...
1. Rather than put this in the sandbox I suggest we go ahead and start
by putting this in a more long term home where we think it should live.
I would vote for the blueprints style of project layout ...
http://java.sun.com/blueprints/code/projectconventions.html
using this layout structure i would suggest that for the Modular Planet
proposal that we start simply by creating an apps/planet directory which
holds build specifics for the planet webapp. eventually we should move
everything there (src, web, etc), but for now if its just a build script
and a few other things then that's fine.
I think that's a good layout and would not be against restructuring the
directories like that, but I have a couple of concerns:
- We want to get a planet app up and running quickly, so is now
the time to restructure directories across the app?
- I'd like to keep things relatively stable so Elias can do his tagging
work in the trunk and perhaps a directory restructuring is too destabilizing.
I've already started in the sandbox and I'll continue there until we find the
right home for the code. I can always move later.
SIDE NOTE: although it wouldn't need to be part of this proposal, i
would also suggest that if we agree to adopt the blueprints layout that
we update other parts of the repository to match for consistency. i.e.
or tools directory -> lib
Yes, but I don't really like lumping all jars into one directory.
2. I'm not sure I understand the need for static generation. Can't we
just do a jsp for pages and use the planetrss servlet? It just seems
like creating static generation code would be doing work that we already
expect to change.
I already have a Velocity/Texen static generation system that works well in
(see PlanetTool in the sandbox). So this is not "doing work that we already
expect to change," it's using code that works now so I can focus on other
issues (like the UI, which is not insignificant).
With the static system in PlanetTool, each planet group can define a control
template that in turn generates HTML, RSS, OPML or whatever else is needed.
By using static generation, we don't need to bring in a page servlet, feed
Servlet or figure out how to do caching. We just let the app server serve up
the pages.
Eventually (3.2 timeframe?), I'd like to have a full rendering system based
on the interfaces you put together in 3.0 but for now static is the quickest
path to working app.
It would probably be a good idea to see a small description of the url
layout for the planet app as well.
Assuming the application is hosted at the root URL of a site, you'd have
a set of URLs for the main aggregation:
http://hostname/index.html
http://hostname/index.rss
http://hostname/index.atom
http://hostname/index.opml
And then a set of URLs for each aggregation group defined:
http://hostname/<group-handle>.html
http://hostname/<group-handle>.rss
http://hostname/<group-handle>.atom
http://hostname/<group-handle>.opml
But the exact file generated is determined by the control template.
- Dave
