> Nico Klasens <[EMAIL PROTECTED]> wrote:
> > The bridge should just be an entry point to the mmbase engine. The 
> > outside world has to go through the bridge to interact with the 
> > engine. The bridge will protect the engine for malicious use. The 
> > engine should be responsible of managing the objects, builders, 
> > modules and other cool stuff. The interfaces of the bridge do not 
> > cover all the functionality and they should not. At least 
> that is how 
> > I see it.
> 
> 
> Yes, of course. But I would really like to see the 'core' to 
> be more bridge-like. Now you have to learn a complete new, 
> and not very friendly, language if you want to add e.g. new 
> functionality to a builder (extending MMObjectBuilder), which 
> is a rather normal thing to do. I'd very welcome a nicer way 
> to do this, and one of the first things which would come in 
> mind is a core implementing bridge (or core and bridge 
> implementing the same sub-interfaces).

Fully agree on that. The core should look like the bridge so it is
easier to predict the flow of method calls throught the mmbase system.
The bridge has some security related methods in the interfaces which are
not required for the core (may...). If you reach the core then you are
allowed to do all the things you want. The bridge interfaces could be
used to force the core implementation to use the same methods to get in.

The core will probably have interfaces with methods to notify custom
builder/module implementations what it is doing. Usually, I
override/implement methods related to notification and not bridge
access. At the moment, it is very vague which methods are called by the
mmbase core  to notify custom implementations.

Nico

----------------------------------------------------------------------
In theory, theory and practice should be the same, but in practice they
never are.


Reply via email to