specific: what should be core/base and what should be external.
Well, e.g. to start with I'd say that all classes in org.mmbase.util which are
not used by mmbase core itself, can be moved to a seperate app.
But I would be reluctant to do so, because for the moment it will only
create problems, and doesn't solve a thing.
You are right in not wanting to refactor out specific classes without
strategy. That would indeed cause more problems than that it would solve.
What should be discussed IMO is the strategy of making MMBase into a
core product with addons that can be loaded into it to gain specific
functionality.
There will be problems in going to a new architecture. Lots of them. For
the sake of the discussion I think it is best to ignore the practical
problems for now (available time, resources, dependencies, etc.) and
focus on the big picture: What would be a good architecture for MMBase?
When we have the bigger picture, we can analyse the state of things as
they are now. We can then estimate the work of migrating from the
current situation versus a major update, where the moloch is killed and
a new base rises from its ashes :)
What I'm saying is, why are we insisting on making life more difficult,
especially when there is _no_ practical gain.
The practical gain is in the future. We need to keep up, or preferably
keep ahead of the competition. There are hundreds of CMS-es, of which
there are tens in the target area of MMBase. There is more than enough
choice of modular, scalable, content focused systems.
More people will choose MMBase if the core is mean and lean and a broad
range of addons are available (as described in eg. the CMS Container
proposal). If the developer community doesn't start growing fast,
combined with the availability of useful addons, my guess is that it is
too late.
Regards, Zoran
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
