It has been mentioned lately that fascilities for creating more 'intelligent' clients for mmbase would require some kind of metadata availability. Some steps have been made to share mmbase config information across the network, but perhaps these could be tuned and formalized? allso the set of metadata and configuration should be as complete as possible, so (rich) clients could be build both for editing data and configuring mmbase.
Ernst > -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Namens Rob van Maris > Verzonden: woensdag 18 mei 2005 11:57 > Aan: Discussion list for developers > Onderwerp: Re: [Developers] Roadmap features request > > > Below is the features list that I gathered sofar. The > annotations are > quotes from the mailinglist, I'll condense these into uniform > descriptions later on. > 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 > _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
