Comments below ...
Dave Johnson wrote:
Thanks for the detailed answer. Comments below...
On 9/8/06, Allen Gilliland <[EMAIL PROTECTED]> 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.
I see what you mean now when you say 'Modular Roller' but that wasn't
really clear to me based on the proposal. My idea of what you were
trying to do was much different.
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.
Personally, I don't think that is a fair thing to say. There are plenty
of reasons why someone may need to share a single tablespace for these
applications. Also, I am not saying that the 2 modules can't share
these tables, I am only saying that by default I don't think they should.
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.
After reading this email it's clear that your plans were much more
complicated than what I was thinking about, so we were talking apples
and oranges. Now that I understand what you want to do it makes sense
and I think it's a very cool idea, but it will take a lot of work and
careful planning to do this.
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.
One thing that I think needs careful consideration given the scope of
your plan is the concept of encapsulation. To be truly modular you need
to provide proper encapsulation, which means that no module should be
able to work around the system and get at information it's not supposed
to have.
I think that properties are a good example of how this could go bad.
Any property that is owned and applies to a given module should not be
directly readable/modifyable by a different module. That breaks the
encapsulation of the module and allows improper intermixing between
modules which are supposed to be functioning independently. So if the
planet module can simply query the properties table for properties that
are owned by the weblogger module then that's a bad thing. The problem
is made even worse when you consider writing data.
To truly allow any number of modules to easily be plugged into Roller
means that the permissions model is going to have to be very tight.
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?
Well, I misunderstood what you were trying to accomplish.
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).
actually, I don't think that the 2 concepts are mutually exclusive. I
think that the 'Modular Planet' is definitely something that we want,
and I think that it makes sense that the long term goal is 'Modular
Roller' which would have a planet module.
the reason I think that both make sense is because I think the planet is
a module which should be able to run on its own, which probably won't
hold true for all other potential Roller modules. many of the other
modules you are thinking about are most likely only going to be modules
that you would plugin to a Roller installation, like a plugin. the
planet is something that should be able to run completely independently
if the user wants it to.
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
quickly.
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
that sounds like a good option to me.
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.
I agree.
-- Allen
- 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:
> <http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_Modular_Roller>
>
> The proposal has a way to go, but comments and suggestions are welcome.
