You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Miguel A Paraz <mp...@gmail.com> on 2005/11/21 16:09:32 UTC
Extensions, Roller as framework (was Re: Planning for Roller 2.1 release)
On 11/9/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> > If people want to add their own feed persistence subclasses based on
> > ROME Modules, I believe it would be good to make this a plugin
> > mechanism.
>
> Good point.
Hi,
I'd like to generalize the concept of plugins or an extension
mechanism. I see Roller as a framework for feed-related apps, which I
believe is closer to the "spirit of the ASF" than a self-contained
app.
I would like the capability to write new apps on top of Roller but
minimizing the impact on the core source code and build process (not
the case with the code I wrote for geoaggregation - had to tweak
build.xml)
Can I work this into a proposal? I would like to work on the following
as ASF-style licensed projects:
1. The geoaggregator - which I can share right now, but it's a bunch of hacks.
2. Integration with Nutch - I'd like to index the URLs the feeds point
to. Of course, this can be done without integration. Nutch can fetch
URLs from the SQL database.
Re: Extensions, Roller as framework (was Re: Planning for Roller 2.1 release)
Posted by Max Rudman <mr...@steelbrick.com>.
I am very much interested in the "blogs tool" idea and willing to
contribute. As I had mentioned, I use Roller as a framework for
custom blogging solutions and would very much welcome greater
separation of concerns and componentization. I haven't looked at 2.0
codebase in great detail yet but I found 1.x codebase a bit
difficult to extend with its liberal use of private and static fields/
methods. On several occasions I had to copy entire classes.
I am a huge fan of Spring and would love to see "dependency
injection" incorporated into Roller. In fact, I can contribute a
Spring-based implementation of org.roller.model.Roller interface
which dispenses manager classes obtained from a Spring XMl-based
factory. This allows to plugin custom business logic implementation
by editing an XML file.
I have a few other suggestions to make Roller a more robust and
extensible product:
1) Clustering: This involves adding distributed caching and search
indexing. I had to solve both problems (not as elegantly as I'd like)
but it's enough to get us started.
2) Transaction management: Currently connections/transactions are
started/closed by Servlet filters which tightly couples business
logic tier to the web tier. Spring elegantly solves this problem, by
the way.
3) Removing persistence/business logic from POJOs (like save()
method). I recall a discussion about this at some point where it was
decided we wanted "smart" POJOs. The problem with keeping such logic
in POJOs is that it makes it difficult to deploy Roller in a truly
distributed environment (eg: rich client accessing managers wrapped
in Web Services and/or EJBs).
Let me know if any of these are of sufficient interest and if I
should propose them in greater detail.
Max
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. 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.)
>
> 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.
>
> On a related (I think) note, I had also been thinking (again
> vaguely) about using Spring dependency injection (just the core
> bean factory and app context stuff) as a mechanism for providing
> more configurable pluggability, initialization, and clean
> separation of components. [Side note: Spring is ASLv2-licensed, but
> another jar to download.]
>
> --a.
>
> Miguel A Paraz wrote:
>
>> On 11/9/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>>
>>>> If people want to add their own feed persistence subclasses
>>>> based on
>>>> ROME Modules, I believe it would be good to make this a plugin
>>>> mechanism.
>>>>
>>> Good point.
>>>
>>
>> Hi,
>> I'd like to generalize the concept of plugins or an extension
>> mechanism. I see Roller as a framework for feed-related apps, which I
>> believe is closer to the "spirit of the ASF" than a self-contained
>> app.
>>
>> I would like the capability to write new apps on top of Roller but
>> minimizing the impact on the core source code and build process (not
>> the case with the code I wrote for geoaggregation - had to tweak
>> build.xml)
>>
>> Can I work this into a proposal? I would like to work on the
>> following
>> as ASF-style licensed projects:
>> 1. The geoaggregator - which I can share right now, but it's a
>> bunch of hacks.
>> 2. Integration with Nutch - I'd like to index the URLs the feeds
>> point
>> to. Of course, this can be done without integration. Nutch can fetch
>> URLs from the SQL database.
>>
>>
>>
>
Re: Extensions, Roller as framework (was Re: Planning for Roller 2.1 release)
Posted by 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)
Posted by 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)
Posted by 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.
Re: Extensions, Roller as framework (was Re: Planning for Roller 2.1
release)
Posted by 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)
Posted by Sean Gilligan <se...@msgilligan.com>.
Dave Johnson wrote:
> 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)
> Big +1 on ASF blog tools idea
I'm a newbie, but I'm really excited by the idea of an ASF Blog Tools
project.
I've been looking at blog software for use in my videoblogging project
for a while now, and have two major constraints in place:
1) Apache-style license
2) Java-based
Given those constraints the choices are Roller, Pebble, and Blojsom.
I've looked at all three and each has its strengths and weaknesses.
Of course, it's a shame to see the duplication of effort. Both Pebble
and Blojsom have file-based persistence and neither require or support a
SQL back-end. Both Pebble and Blojsom have some level of "pluggability"
in their persistence layers, but writing a SQL persistence layer is
non-trivial.
Blojsom has probably the nicest library of templates. (I'm much more
comfortable with velocity than JSP, so I like velocity templates.) It
would be cool if there were some "standard" for the velocity context
that say Roller and Blojsom and others could agree upon so that
templates could be shared between Java/Velocity blogs.
I think it is really hard for an open-source Java blog project to
compete with one in PHP, because so many blogger/developers use hosting
services that support PHP and not Java, and because the learning curve
for Java is much steeper. For example, WordPress has 100's of templates
and 100's of plugins.
I've even thought it might be cool if a Java blog could use WordPress,
MT, or Blogger templates in a compatibility mode. (I realize this is
not a trivial thing to implement.)
So, in hoping for something like an ASF Blog Tools project, solving some
of these duplicate work issues especially around templates and plugins
could really help to narrow the gap between available Java and PHP blog
software.
My ideas here are, of course, much bigger than my ability to contribute,
but a modular approach like that would increase my ability to re-use and
therefore contribute to the project.
-- Sean
Re: Extensions, Roller as framework (was Re: Planning for Roller 2.1 release)
Posted by Dave Johnson <da...@rollerweblogger.org>.
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.
> 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).
> 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
- Dave
Re: Extensions, Roller as framework (was Re: Planning for Roller
2.1 release)
Posted by Anil Gangolli <an...@busybuddha.org>.
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. 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.)
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.
On a related (I think) note, I had also been thinking (again vaguely)
about using Spring dependency injection (just the core bean factory and
app context stuff) as a mechanism for providing more configurable
pluggability, initialization, and clean separation of components. [Side
note: Spring is ASLv2-licensed, but another jar to download.]
--a.
Miguel A Paraz wrote:
>On 11/9/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>
>
>>>If people want to add their own feed persistence subclasses based on
>>>ROME Modules, I believe it would be good to make this a plugin
>>>mechanism.
>>>
>>>
>>Good point.
>>
>>
>
>Hi,
>I'd like to generalize the concept of plugins or an extension
>mechanism. I see Roller as a framework for feed-related apps, which I
>believe is closer to the "spirit of the ASF" than a self-contained
>app.
>
>I would like the capability to write new apps on top of Roller but
>minimizing the impact on the core source code and build process (not
>the case with the code I wrote for geoaggregation - had to tweak
>build.xml)
>
>Can I work this into a proposal? I would like to work on the following
>as ASF-style licensed projects:
>1. The geoaggregator - which I can share right now, but it's a bunch of hacks.
>2. Integration with Nutch - I'd like to index the URLs the feeds point
>to. Of course, this can be done without integration. Nutch can fetch
>URLs from the SQL database.
>
>
>
>