roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Johnson" <>
Subject Re: Modular Roller
Date Mon, 11 Sep 2006 19:35:20 GMT
Thanks for the detailed answer. Comments below...

On 9/8/06, Allen Gilliland <> wrote:
> I think the proposal makes sense, but before we get into too many
> details about how to reorganize the code I think it would be good to
> make sure we agree on the general approach of how these 2 pieces of
> functionality should interact with each other.
> At a high level I would expect that each component (weblogger and
> planet) should be packaged separately like you said, and neither
> component should have any direct knowledge about the other.  I think
> this is pretty much expected for modularization.

Right. Those two components are the modules that can be added
to the Roller core.

> At a slightly lower level I think that means that each component should
> only have code/configs that know how to run itself.  Meaning that they
> can't share any db tables, they can't share any config files, and they
> can't share any code (aside from explicit utils/interfaces which are
> meant to be shared).

No, that's wrong. The Modular Roller proposal is to have a shared
core that includes user management and configuration.

I think what you have in mind is better characterized by the words
"Modular Planet" which is not a bad idea -- it's just different from the
Modular Roller concept I have in mind. I'll describe what I mean by
Modular Planet below.

> Now, getting to the specifics of how you broke things down in the
> proposal.  I would like to see a little more detail about what things
> you think belong in the "core" module.  You have quite a bit of stuff
> listed under "core" which I'm not sure really works.

Yes. My list is defintely too aggressive. I'm trying to imagine all
of the things that could possibly be used by all modules.

> For example, you have all the user management listed under core, but I
> don't think that weblogger and planet should have to share the same user
> management code.  what if someone wants to deploy both weblogger and
> planet in the same database but not have them share users?  that would
> be impossible.

If you want that -- you don't want to share anything -- then install
Roller Planet and Roller Weblogger into two different table spaces.

The concept in the Modular Roller proposal is that the Roller core
is a web application with a Main Menu and a tabbed Administration UI
that provides a configuration system. Modules plug in to the core
and can provide, additional Manager interfaces, Struts Actions, JSPs
and Servlets. But they also plugin UI and additional configs:

- A JSP file that provides additional content for the Main Manu
- A configuration defintion file that defines additional properties
for the config page
- An admin-menu.xml file that defines additional tabs for the Admin UI
- An module-menu.xml that defines module's tabbed UI.

The Admin UI is part of the core and modules plugin to it.

So when you plugin the Planet Module, users get the ability to
create planets. And the Main Menu lists not only your weblogs
but also your planets. A user can have multiple planets and a
planet can have multiple users -- just like a weblog. Members
of a planet can create aggregation groups within the planet,
edit the page templates that define the pages and feeds of the
planet, etc.

A planet is so much like a blog -- with users, settings, page
templates, caching, feeds, etc. -- that it will make sense to
share a lot of infrastruture.

> You also have the properties manager shared, but I think
> that's a bad idea because then both modules are sharing a single
> properties table which goes against the modularization.  *if* something
> should be shared then it should be shared by providing a custom
> hybridized implementation of an interface which knows how to interact
> with both systems.  i.e. a  RollerPlanetUserManagerImpl or a
> RollerPlanetPropertiesManagerImpl could be used in place of the default
> PlanetUserManagerImpl and PlanetPropertiesManagerImpl to allow users
> from the "weblogger" module to be shared with planet.

The idea of a shared configuration system is a key aspect of
Modular Roller. Modules plugin to that and provide additional
properties -- but that doesn't preclude having separate tables
and config files.

> When I look at the src tree the only things that I think are truly core
> and could be shared would be these things ...
> business.runnable (general purpose interfaces for running tasks)
> util (some generic utility classes)
> util.cache (generic caching framework, CacheManager can't be shared)
> and even though those things could be shared i'm not sure it's really
> worth it to require sharing them rather than just duplicating the small
> amount of code.  one problem with sharing them is that then if you want
> to modify something in core you could be forcing changes in both modules
> when the change is really only need to benefit one of the modules.

You just came down against the whole idea of a core with modules,
or did I misread that?

> at first glance i think it would be fine to simply take out all of the
> planet specific classes and put them in their own module under the
> org.apache.roller.planet package and just duplicate the small number of
> classes which need it.

I think what you have in mind is a "Modular Planet" concept where we
move the Planet code to it's own package, JSPs to their own directory
and we essentially have a planet module that can plug in to the Roller blog
server or into some other (yet to be created) web application.

I prefer the Modular Roller concept. I think it provides a better experience
and we'll benefit greatly by sharing a strong core application. Later, we could
add other modules like a Photo Gallery module, a Poll Creator module --
and because they are modules users on a Roller server could access them
and even integrate them into their blogs (with the right page models).

But... modularizing Roller as I have described will take a lot of work --
including a fair amount of Strutsy JSP work (I'm not real excited about that).
That's bad because we want to get a standalone Planet up and running

So perhaps in the short run, we should do Modular Planet instead:

- Keep Roller release as is, ships with integrated Planet as is
- Separate Roller code into core, weblogger and planet
- Core is intially only caching and other utils
- Separate Planet code into it's own directory, depends only on core
- Create separate RollerPlanet web application
- RollerPlanet gets simple UI that allows one planet, admined by global admin

In the longer term, we figure out how to create Modular Roller so that
Roller users and groups of Roller users can create and admin their own
planets, photo galleries, etc.

- Dave

> Dave Johnson wrote:
> > Looks like I may have a requirement to deploy Planet independently of
> > Roller (but with Roller's Planet UI and the Roller rendering/caching
> > system). And others on the list have also expressed interest in
> > modularity. So I've started to think again about how to break up the
> > Roller code based into core, weblogger and planet modules.
> >
> > I updated the proposal with some of my latest thinking:
> > <>
> >
> > The proposal has a way to go, but comments and suggestions are welcome.

View raw message