Re: Extensions, Roller as framework (was Re: Planning for Roller 2.1 release)

[Allen Gilliland <Al...@Sun.COM>]

On Mon, 2005-11-21 at 09:12, Dave Johnson wrote:
> On Nov 21, 2005, at 11:34 AM, Anil Gangolli wrote:
> > This is likely to be controversial territory.  Consider this a 
> > brainstorm, and not an expression of firm opinion. I confess I'd been 
> > thinking along similar lines for Roller 3.x or possibly 4.x, at least 
> > that we should be considering rearchitecting around a data/event model 
> > that allows developers to hook in at natural points in the lifecycle 
> > of blog entries and possibly other types of elements in a blog model.
> 
> Having a good plugin model shouldn't be controversial, its something we 
> need and the existing plugin proposal doesn't really go far enough.

I'm not sure that what Miguel meant by plugin is the same thing you are thinking of.  The original email was fairly ambiguous, but I got the sense that Miguel was talking about some far more fundamental changes than what we consider plugins right now.

> 
> 
> > This would involve factoring out elements of the app and developing 
> > more of an "engine" as the heart of the app, producing a core which 
> > may eventually be separable from Roller the app.  Roller itself 
> > arguably already contains two apps: the "blog authoring/publishing 
> > app" and the "aggregator app" (Planet).  (Both of Miguel's suggestions 
> > seem to involve extensions along the aggregation side more.)
> 
> I'm definitely in favor of refactoring and separation of concerns. I 
> hadn't thought of separating out the aggregator; I believe a blog 
> server needs a build-in aggregation engine. I was thinking of three 
> layers:
> 
>     Roller core (business logic, persistence)
>     Roller blog engine (page/feed rendering, web services)
>     Roller UI (Servlet based user interface)
> 
> I'd like to make it possible to switch out the Roller UI with something 
> new (something which might not have a dependency on Struts for 
> example).

don't we already have that to a large degree?  there is certainly room for improvements here and there, but I would certainly say that we already have the above separation.

> 
> 
> > However, my ideas around this have remained pretty vague, and I'm not 
> > positively convinced this is a good idea for Roller the app(s?) and 
> > the present Roller community, though it might be very good for a 
> > developer community spawning other apps built around an ASF blog tools 
> > core.
> 
> Big +1 on ASF blog tools idea

I am thining along the same lines as Anil on this one.  It's hard to tell exactly what Miguel wants to do without seeing a more complete description, but if the approach is as grandiose as it sounds then I would be hesitant.  I am certainly in favor of making things pluggable, but I would not agree to expand the app to do things it really doesn't need to do.

-- Allen


> 
> - Dave
> 

Re: Extensions, Roller as framework (was Re: Planning for Roller 2.1 release)

[Miguel A Paraz <mp...@gmail.com>]

On 11/22/05, Allen Gilliland <Al...@sun.com> wrote:
> So, I think what you have on your site looks pretty cool, but I'm not
> sure I see why it should be part of our core application?

I don't think it should. But I want to maintain it without hacking at
the Roller core, so I could publish it as a separate package/jar that
users could deploy on top of Roller.

> I think that we can definitely do some things to make some of your
> modifications a bit easier to plugin to Roller, but I don't think you
> are ever going to have a way to store additional data like your latitude
> and longitude data without hacking at the application a bit.

While building it, I thought it's possible. The geo info is in a
separate table that joins against rag_entry. The class is a subclass
of PlanetEntryData in a separate package. To generalize, I think
plugin authors can use Hibernate subclasses to do it.

> To be totally honest, I think I would like to see a little *more*
> separation between our Planet Roller aggregation tools and the core
> Roller blogging tools.  I am just thinking out loud right now, but I
> like the idea that a Roller admin could download both of those
> components separately and piece them together if they wanted to.
>
> In any case, I prefer to have a more trimmed down application that is
> more focused, rather than adding more and more stuff.

By that line of reasoning: many of the Roller features can be separate
plugins (or Spring-managed beans  if we adopt that framework). The
separation between aggregation and blogging can be the basis of a
blogging tools suite, and Roller as it stands right now their
integration.

Re: Extensions, Roller as framework (was Re: Planning for Roller 2.1 release)

[Allen Gilliland <Al...@Sun.COM>]

So, I think what you have on your site looks pretty cool, but I'm not 
sure I see why it should be part of our core application?

I think that we can definitely do some things to make some of your 
modifications a bit easier to plugin to Roller, but I don't think you 
are ever going to have a way to store additional data like your latitude 
and longitude data without hacking at the application a bit.

To be totally honest, I think I would like to see a little *more* 
separation between our Planet Roller aggregation tools and the core 
Roller blogging tools.  I am just thinking out loud right now, but I 
like the idea that a Roller admin could download both of those 
components separately and piece them together if they wanted to.

In any case, I prefer to have a more trimmed down application that is 
more focused, rather than adding more and more stuff.

-- Allen


Miguel A Paraz wrote:

>On 11/22/05, Allen Gilliland <Al...@sun.com> wrote:
>  
>
>>I am thining along the same lines as Anil on this one.  It's hard to tell exactly what Miguel wants to do without seeing a more complete description, but if the approach is as grandiose as it sounds then I would be hesitant.  I am certainly in favor of making things pluggable, but I would not agree to expand the app to do things it really doesn't need to do.
>>    
>>
>
>My needs are not grandiose. :) My changes can be done without hacking
>Roller, so I'd like the infrastructure for that.
>
>For my current work, temporarily running at:
>http://recovery2.blogdns.org:8080/roller/ , I
>
>1. Stuffed in a new ROME module (their name for "plugin" it seems )
>for parsing GeoInfo, but I had to hack PlanetManagerImpl to add module
>checking
>2. Added a joined-subclass for PlanetEntryData to hold the
>latitude/longitude. This did not break the existing tables but added a
>new one.
>3. Added an Action to draw the Google map, filtering out only
>aggregator entries that were instanceof my new joined-subclass.
>
>These 3 were in my own package hierarchy under src/ so I'd like the
>ability to publish this in the jar.
>
>The other changes:
>4. A new JSP in web/planet as the view for the Map Action
>5. Since I just stuffed #1-3 in the same source tree, I had to hack
>build.xml which relies on a bunch of includes/excludes based on
>package name. Nice if we could have separate trees for the parts with
>different dependenices.
>6. (not done) Publish a new aggregator feed with the GeoInfo. I don't
>know if a Velocimacro can do instanceof to publish selectively-  think
>no.
>
>My plans are at:
>http://migs.paraz.com/w/archives/2005/11/10/roller-based-geo-aggregator/
>
>For the code, I could tar it up or diff it for your inspection.
>
>I believe a dependency-injection approach would be good for
>modularity- Roller or the proposed ASF blogtools could be
>Spring-hosted like say, ActiveMQ.
>
>Even if my needs at the moment are on the aggregator part, I think
>blog server authors would like Roller as a toolset which they could
>break apart to get the parts they need.
>  
>

Re: Extensions, Roller as framework (was Re: Planning for Roller 2.1 release)

[Miguel A Paraz <mp...@gmail.com>]

On 11/22/05, Allen Gilliland <Al...@sun.com> wrote:
> I am thining along the same lines as Anil on this one.  It's hard to tell exactly what Miguel wants to do without seeing a more complete description, but if the approach is as grandiose as it sounds then I would be hesitant.  I am certainly in favor of making things pluggable, but I would not agree to expand the app to do things it really doesn't need to do.

My needs are not grandiose. :) My changes can be done without hacking
Roller, so I'd like the infrastructure for that.

For my current work, temporarily running at:
http://recovery2.blogdns.org:8080/roller/ , I

1. Stuffed in a new ROME module (their name for "plugin" it seems )
for parsing GeoInfo, but I had to hack PlanetManagerImpl to add module
checking
2. Added a joined-subclass for PlanetEntryData to hold the
latitude/longitude. This did not break the existing tables but added a
new one.
3. Added an Action to draw the Google map, filtering out only
aggregator entries that were instanceof my new joined-subclass.

These 3 were in my own package hierarchy under src/ so I'd like the
ability to publish this in the jar.

The other changes:
4. A new JSP in web/planet as the view for the Map Action
5. Since I just stuffed #1-3 in the same source tree, I had to hack
build.xml which relies on a bunch of includes/excludes based on
package name. Nice if we could have separate trees for the parts with
different dependenices.
6. (not done) Publish a new aggregator feed with the GeoInfo. I don't
know if a Velocimacro can do instanceof to publish selectively-  think
no.

My plans are at:
http://migs.paraz.com/w/archives/2005/11/10/roller-based-geo-aggregator/

For the code, I could tar it up or diff it for your inspection.

I believe a dependency-injection approach would be good for
modularity- Roller or the proposed ASF blogtools could be
Spring-hosted like say, ActiveMQ.

Even if my needs at the moment are on the aggregator part, I think
blog server authors would like Roller as a toolset which they could
break apart to get the parts they need.