You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Allen Gilliland <al...@sun.com> on 2007/01/13 01:23:05 UTC
Roller Planet application, next steps
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
Re: Roller Planet application, next steps
Posted by Dave <sn...@gmail.com>.
+1 on those 3 things and thanks for outlining your plans here on the list.
- Dave
On 1/18/07, Allen Gilliland <al...@sun.com> wrote:
> 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
> >
>
Re: Roller Planet application, next steps
Posted by Allen Gilliland <al...@sun.com>.
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
>