I haven't heard any comments on this so this is a friendly reminder. I
am planning to move ahead on these items and would likely have something
ready to commit for early next week, so if you object to any of these
changes then please speak up.
-- Allen
Allen Gilliland wrote:
All,
I currently have a need to put some development effort into enhancing
Roller's planet aggregation code a bit and working to really build it
out as it's own webapp. Dave has already done some work on this and he
also has some development plans on the wiki right now ...
http://rollerweblogger.org/wiki/Wiki.jsp?page=RollerPlanetMindMap
Since this standalone planet app is currently unreleased we are
basically free to do whatever we want at this point, but I think that
Dave has outlined a good dev path for the application in his doc above
and that is pretty much in line with the work that I am hoping to do
coming up. We can talk more about how the whole application will come
together as needed, but in the short term there are a few things that I
think are safe enough and important enough to try and accomplish now.
There are 3 things in specific that I want to do ...
1. Fix up the data model to allow for any number of planets with any
number of aggregation groups in a planet. This is a simple parent child
relationship. This would be done by create a new rag_planet table to
track each planet.
The second change to the data model would be to ditch the current
rag_config table and replace it with a rag_properties table like the
current roller_properties table. This makes it easy to define site-wide
property data in the db in an expandable way.
2. Begin a well defined url structure. Something similar to the Roller
Weblogger url structure ...
/<planet>/
/<planet>/group/<group>/?page=X
/<planet>/group/<group>/feed/<fmt>
/<planet>/group/<group>/opml
/planet-ui/* (UI stuff)
The current plan is necessarily simple and doesn't provide url endpoints
for a lot of the same things in roller such as resources, pages, search,
etc. I can't tackle all of that stuff at one time, but the url
structure is setup with those things in mind so they are easy to add
when needed. An example of how they might be added would be ...
/<planet>/search?q=<query>
/<planet>/page/<pageName>
/<planet>/resource/<uploadedResource>
3. A reasonable web framework to work from. Currently the planet app
uses JSF, but from my experience playing with that code and Dave's
description of his experience it sounds like we aren't particularly
thrilled with JSF. So, I'd like to suggest that the planet UI be a
testing ground for Struts2 work.
So, anyone have any thoughts about any of those things? #2 is the most
important one to me right now.
-- Allen
