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.
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 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 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: > <http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_Modular_Roller> > > The proposal has a way to go, but comments and suggestions are welcome.
