Any more suggestions of features to add?
Regards, Rob
FEATURES LIST:
- generic workflow support
- a standardized and documented packaging system
- an alternative for the editwizards, that is easier to customize and extend
- multilanguage support
- standard 'site framework' ('cms container'?)- multicloud (i.e. making it possible to link to objects in another mmbase
installation)
- cleaning and optimizing
- (better) versioning/transactions (may overlap with workflow)
- customizable caching framework (2)
- core2 (Bridge node managers) (3)
- java developer and framework friendliness (1)
ANNOTATIONS:
(1) Kees J:
When developing mmbase based applications that do not use the mmbase taglibs
an great amount of custom programming has to be done.
40% of that code is creating simple or complext queries
40% of that code is O/O mapping (MMBase objects to struts forms or
something else)
and I think that most of this code should not be required, this can be
done in several wayss
on the O/O site 1-provide a better more flexible way to extend nodes (so the O/O mapping is not required) 2-provide utils to perform basic O/O mapping (fill lists of obects based on a nodelist)
on the querying site
-1more utils like org.mmbase.bridge.utils.Queries ( and show how to use then)
-2provide a taglib like format to perform queries
This all helps when de developer is doing the "real" jobs.
developer friendlyness can also be something like a doclet that helps in creating the mmbase cloud, why not a doclet that also defines queries used!
(1) Ernst B: well, i suppose the main thing that could vary is flushing rules/policy.
for instance if i want to cache a forum, i want a mutable cache, that communicates it's changes to instances on other servers within the cluster through some messaging (not just flush, but update). This cash would be of a tree-like structure and perhaps would read query objects and map queries to specific entries in the cache tree, which could be more efficient (memorywise) than just caching all the queries on the forum. So mmbase would have to allow for inserting a cache somewhere in the storage layer before the database access. A cache would than descide if it wants to serve the data request or send it on to the db. I could even imagin a sort of caching pipeline (i mentioned this before) that all the queries are send thrue. every cache has it's own filter, and the nodecache and the multilevel cache would come last, as 'default' caches.
I'm shure other spcialized cache types could be thought of that could greatly releave database traffic, and make mmbase more sutable for (very) dynamic websites (which it is not realy at the present)
So what this boils down to is: -a formal insertion point for all caches (in the storage layer). possibly like a pipeline where caches pass on data requests they can not serve themselves, and where the caches are chained in a configured order. -some kind of mechanism would have to be in place to synchronize mutable caches.
Another idear i have concerns the present multilevel cache. Would it not be a nice idear to cache only metadata in the multilevel cache, and refer for all the actual data to the nodecache? this way updates to specific nodes would not have to result into cache flushes anymore. Allso the multilevel cache could store many more queries becouse the memory useage would be very modest.
(3) Pierre vR:
A new core implementation that implements the bridge interface and possibly allows for some new features such as extending nodes. It would also be in a more logical package than org.mmbase.module.core
Emile:
I think a seperation of layers would be advisable, but in a more abstract
fashion than "core" and "bridge" - how about Toolset, Services, Application
and Package (such as CMS - which is functionality consisting of multiple
applications and services).
Obviously, the more generic stuff filters it's way to the bottom of the
layered structure, whilst the more specific stuff filters it's way up.
There are also dependencies and these should be identified, otherwise you
run the risk of generic code being done at an application or package level,
whilst the toolset does not grow - which means that many developers are
repeating the same generic tasks, whereas they could be built once in the
toolset which everybody will benefit from them.
_______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
