> Eduard Witteveen <[EMAIL PROTECTED]> wrote: > > Pierre van Rooden wrote: > > >We cannot remove these methods from the bridge, as they have been in use > > >for over two years. > > >Obviously when adding _new_ methods we don't need to add extra > > >shortcuts, but we cannot remove the old methods. > > Cant be the new classed / interface's be placed inside a different > > directory? > > Lets say a org.mmbase.api / org.mmbase.bridge2? (i'd say make it all
> > classes) The bridge would than be the extending / scripting part of the > api. > We are not planning a new layer near the bridge. We are only busy making > the > current bridge interfaces (and corresponding basic implementations) more > powerful. I think some of the more exotic legacy-ish functions as for > example the createQuery version of getList(String, String.. few times more > .., boolean (or so)), will not be placed in the bridge, but in a utility > static class org.mmbase.bridge.util.Queries or so. So, if I want to use the power of the SearchQuery then I have to use a util? Hiding the SearchQuery is great, but hiding the method using the SearchQuert? > I think bridge must remain to be a set of interfaces because alternative > implementations are imaginable. (RMMCI, core2) Is this true? I thought that RMMCI was a wrapper around the bridge. The generated sources are receiving an original object (bridge interface) IIRC. Core2, will that be the replacement for the core in the architecture image? (http://www.mmbase.org/download/builds/2003-08-28/mmdocs/general/media/a rchitecture.png) That is below the security right and the bridge is above it. Core2 shouldn't affect the bridge api then. Only the calls from the bridge to the core. Nico Klasens ---------------------------------------------------------------------- Efficiency is a highly developed form of laziness
