Nico wrote:
> MMBase web application - An web application which uses the binaries from
> mmbase.org
Hey, I always build my own binaries :-)
> Module
> A module adds service functionality to the system. It could perform task
> like indexing,
> cleaning, etc. It could also start a service which listens to remote
> requests.
I'm beginning to see a module as 'something wich is automaticly initialized
together with mmbase, and which provides a crude configuration mechanism
(properties only). You can add functionality to MMBase without extending
org.mmbase.module.Module though. Perhaps that would not be what you call
> · Query caches – These caches contain result which are retrieved by a search
> query.
> The last two cache types are to reduce the load on the database. They can be
> used by the
> storage subsystem. The cache system shouldn’t be seen by other subsystem
> then the storage.
> The storage subsystem has all the information to keep the cache system up to
> date with the
> database. The storage and cache systems should be in a stable state after
> each action from
> another subsystem. This is currently not the case with MMBase, because the
> caches are
> updated by the event system.
> IMO, we should also consider when to use Query caches, because they usually
> contain
> queries which are just as fast in the database as the cache is. Just to make
> a small comparison,
> hibernate does not recommend to use their query cache. Hibernate is used in
> application
> which have equal or more updates than reads.
I think we could consider the cost of the query as a criterium for whether
to cache it or not. I think this would be quite easy using the
'CachePolicy'. It could be a simply configuration option 'if the query took
over 100ms, then cache its result'.
> Search
> MMBase has a search api to develop code which is database dialect
> independent. The api
> currently has two issues. First it is part of the storage layer so it is
> duplicated in the bridge.
Bridge is only extending on the interfaces, not duplicating it.
> The api should get a generic part in its own package and a part
> (QueryHandlers) should stay
> in the storage layer. Second the api is elegant in design, but not easy
> to use in development.
> Query code requires now too many lines of code to make a simple query.
I agree. Though I think that in the bridge we address this issue by
providing utils, and the Query interface itself.
I'm not satisfied by it though, because e.g. all 'createConstraint' method
implmentations are forced to cast real interfaces to Basic-
implementations, which is quite ugly.
> The third are ClusterNode and ResultNode. These nodes remove the restriction
> of one node
> type per node. Both nodes can have multiple node types corresponding to the
> tables used in
> the query which loaded the instances. Instances of these types are not fully
> loaded instances of
> one node type. They combine the fields which are mentioned in the query. The
> real difference
> between ClusterNode and ResultNode is not clear to me. The ResultNode is in
> the storage
> search package and might be introduced for the same purpose as the old
> ClusterNode for
> multilevel queries.
I think a ResultNode is even more general, it can e.g. contain the result
of a count query. It is no cluster-node because it is not a combination of
other nodes.
> There are three type of fields in MMBase. Again, these are not datatypes,
> but conceptually
> different types.
> One, the persistent field which is mapped to a column in the database.
> Two, the virtual field which can be used to calculate a value based on
> external data like
> persistent fields or values in an external system.
I consider this more or less deprecated becasue I find a function on the
node cleared, and you can also have parameters then. A function with no
paramter is like a virtual field.
> Three, temporary fields. These fields are hidden from outside the system,
> but can be used to
> do some administration. Temporary fields start with an underscore.
This bothers me a bit. Because there are not very well hidden. I would
propose a new Map in MMObjectNode for these, to make the hiding complete,
and the need for the underscore obsolete.
> Security
> Security is handled by the bridge at the moment. Some security features in
> web applications
> are done by the taglib (eg login methods). MMBase does not use the j2ee
> security api and
> does not work well together with the application server container security.
> You always have
> to write your own Authentication class when you don’t administer users in
> the MMBase
> system
er.
> Module
> A MMBase module can be used to start additional services for an application.
> In previous
> releases I usually used modules to start threads for maintenance tasks, but
> the crontab feature
> is better suited for this. Other ways of usage are to start listeners like
> rmi, smtp, irc, etc.
> The only peculiar thing about the modules is that MMBase is a module of its
> own. IMO, this
> should change. MMBase should be the system which starts all subsystems
> including the
> module sub system.
I think I agree.
> the storage layer is in a stable state again and all node type extensions
> are processed.
> The only thing which is still not discussed is the api to interact with
> MMBase. In MMBase
> terms this is called the bridge. The bridge has been added to MMBase to make
> it possible to
> use several templating languages with MMBase. The bridge was and in most
> cases still is a
> wrapper layer with security features. This has been sufficient for some
> years, but not anymore
> as the fieldtypes project has shown. The wrapper class Field and Node in the
> bridge have now
> features which should have been added to a class which could be used in the
> bridge and core.
> I like to change the role of the bridge in the MMBase system. The bridge
> should become a
> user session for the MMBase core system. Nodes are loaded into the user
> session and the
> session tracks changes. A user session can be committed back to the MMBase
> core. The
> cloud object should become a session like hibernate or jsr-170 uses to let
> code interact with
> the system.
That would make a Cloud more or less what a Transaction is now?
If you do Cloud transation = cloud.createTransaction() en then use the
'transaction' boject then more or less already happens what you are
proposing here, isn't it?
> Changing the role of the bridge to the above will make the core system
> responsible for the
> repository data stored in the database. The core is not responsible to track
> changes in field
> values. The core is responsible to handle the commit of changed field values
> in an ACID way.
> The core system should return in a stable state after each commit has
> finished.
> The cloud/user session loads a node from the repository into its own space.
> After the load, the
> cloud has a snapshot of the repository when it was in a certain state. The
> cloud will always
> return the snapshot version instead of the version in the repository. A
> search with criteria in
> the repository could return the node even when the snapshot version does not
> match anymore.
> The above means a big change in the core code, Most of the functionality is
> currently in the
> MMObjectNode class. This change does not affect the way a developer uses the
> bridge. The
> developer already has to call commit on nodes and transactions to persist
> the changes in
> MMBase.
> When we make this change then all custom builders and modules (which are
> using
> MMObjectnode) won’t work anymore, because the changes are not tracked by the
> MMOBjectNode class. We need a new way to create a custom builder.
I do think that what you describe, the bridge becoming more and more the
new 'core', is a correct perception. And I agree that we could supply a new
way to override the complete Node using only bridge interfaces. Or the
NodeManager. I always thought that implementating all features of
MMObjectNod in MMObjectBuilder was a bit strange, so I would even consider
offering the possibility to override both levels seperately.
Perhaps it would not be very hard to add e.g. to specify a NodeManager
and/or Node implementation in the builder xml, and make the bridge
instantiate those then in stead of BasicNodeManager and BasicNode when
necessary. That would please me, at least. We can also reimplmented
BasicNodeManager to not use MMobjectBuilder any more (but e.g. wrapping
CoreNodeManager), and provide an MMObjectBuilderNodeManager for backwards
compatibility.
Michiel
--
Michiel Meeuwissen mihxil'
Peperbus 107 MediaPark H'sum []()
+31 (0)35 6772979 nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
