Hello Ernst,
Your perception on what Finalist thinks of MMbase is not the same as we
(or at least I) think of MMbase. This email is my personal writing, but
I am confident Finalist is on the same line.
In the past years we (Finalist) have selected frameworks and products to
use in our custom-made applications. The selection process is based on
what customers want, what we think can help in implementing quality
applications and eases development. We have seen that MMbase is not
always high-quality, but it is versatile and that is what customers
want. It is also very flexible which makes development easy.
MMBase is NOT a fancy database. It is a data repository which is backed
by a database. A database lacks many data management features a data
repository has. Examples of these are: search, notification, access
control and type, object and relationship management. In the java world
you can choose now between a pojo based persistency framework
(EJB/hibernate) or a data repository (MMBase, Jackrabbit).
One of the weaker points of MMbase is that it does not communicate which
concepts are used, which design decisions were made and how it prefers
to do thinks. Some of the answers can be found in the code and some in
the community. I am involved for a few years now, but I am still
searching. I am happy to hear what the 'mmbase way of things' is. (+1
for the principles)
The current cmsc demo includes these mmbase dependencies: mmbase.jar,
mmbase-cloudcontext.jar, mmbase-dove.jar, mmbase-editwizard.jar,
mmbase-email.jar, mmbase-rmmci.jar, mmbase-taglib.jar. Some others will
be used when we add some things from the wishlist.
The cmsc makes a clear distinction between content repository and site
management. The sole reason for this is to be able to use the content
repository and another site management implementation.
We decided to use pluto as the base for our small portal product. We
have considered to use one of the other portal products (Liferay,
jetspeed, jboss portal, etc) which would push MMbase in a position as
external information system. These portal products provide many advanced
features which some of our customers might need. We decided to use pluto
and a stripped portal implementation to reduce complexity to have a
better change of acceptance in the mmbase community. We also made sure
that the mmbase taglibs could be used inside portlets. At the moment,
MMbase is the base library in the cmsc. All other libraries are just
utilities.
The initial and still the main goal of the cmsc is to solve several
development issues. It is nice that it has also benefits for our
customers. We are spending time on this MMbase framework, because it has
some of the same goals as we have set for the cmsc. The cmsc can be a
test case for this framework. The framework is a success when we and
someone else are happy in the way it works. It is a great success when a
jsp based webapp and our cmsc can both benefit from it.
We don't want to change MMbase to fit the cmsc. We also don't want to
change the way you can develop with MMbase. We are only suprised that
you can more easily develop with the taglib then with the bridge. Many
of us expected to have a mmbase engine with an mmbase api. The api
should allow applications to interact with the engine. All other tools
(taglib, editors, etc) only makes it a better product to choose it as
the base for a custom-made application. Many of us know how to apply
other frameworks to solve specific issues. Not being able to use
features (because they are only implemented in the taglib) makes MMbase
a less interesting product for us. If MMbase prefers the taglib above
the bridge then it should communicate that. We will accept that decision.
As I understand from the below email, MMbase should more rely on code by
convention? Then MMbase and Java are not a good fit. Java is a very
type-safe programming language. Especially now in java5 with typed
parameters. Not using the strong points of Java is a loss to me.
I think, it is very narrow minded to say that default builders will be
enough to solve all component type issues. It is also a lot of work to
migrate a database to integrate the default builders. Currently, several
organizations have invested a lot in their mmbase systems and they are
not going to like it to convert them. Ease of collaboration is still
requested.
The development meetings about this subject did send us a clear message
that what we visioned was not the same as what the mmbase developers had
in mind. This is one of the reasons that we dropped the name karma. We
will contribute with feedback to the mmbase component framework to make
it a success. Next to this we continue to set out a repository standard
in the mmbase world. We like to deliver several mmbase components which
together create a base system for a content repository application. The
first is important to you, the second is important to us.
Regards,
Nico
Ernst Bunders wrote:
hi
I will not react to your document point by point. I would rather react
to the assumptions (i think) lie behind it.
There is a lot of talk about the need for a framework or container
that can make bits of functionality work together. This is a very good
idea.
What i wonder though is how this should be approached. Finalist chose
for a very 'dominant' solution, where the the role of mmbase is
marginalized to that of 'datapump'. I feel there is not a lot of
attention for what is already there and what approach is in line with
the 'mmbase way of things'.
Mmbase has a lot of power in the tag lib, so what happens is that a
lot is being done in templates. Adding functions to the equation even
made this a more attractive approach, striking a nice balance between
presentation-code separation and ease of use.
If you would have to implement java interfaces to translate the
functionality of your application to the container, you loose that
power, and you may loose investment in developed functions as well, if
it turns out that calling functions is not a conveneant way to
implement the interface. The whole thing becomes very java-centric
which i think would be a loss.
Personally i would rather see a move in the other direction where it
becomes more and more easy to develop with mmbase, also for non-java
programmers. Idears in that direction comprise adding scripting
support for scritable functions and system callbacks, and development
of better (gui) tools.
So, i think that if you want to address the problem of reuse of mmbase
functionality, you should try to do it as non-obtrusive as possible.
this can be achieved in several ways:
- strong convention: (i don't need a java interface to a functionality
if i can look at the cloud design and use it with the tag lib.)
- formalizing existing solutions
- think of clear boundaries to the areas you want to manage (don't
manage everything)
So: builder name blurr can be overcome by choosing default builders
(we don't need mixin for that), also by using application dependencies
you can already define collaboration between functionality and reuse.
I think the apps1 spec is not complete, and apps2 is still hanging
there.. Still, maybe this is all we really need. Maybe we should focus
more on creating those applications, that use each other and integrate
well, and provide the documentation and information needed to reuse
them successfully.
Perhaps special attention should go to how different 'applications'
interact in one screen. The portlet spec. has an answer to that, but
perhaps we could think of something that is much more in line with the
current way of things. Something more lightweight, again more based on
convention. Something that is just as easily used as ignored.
I can imaging the mixin idea can be very interesting if this means you
can define 'meta objects' what i mean is an object consisting of
different nodes. Say, an article meta object, consisting of an article
node, some paragraph nodes, and some image nodes. I can imagine that
could have a lot of use (also for import export purposes).
So, in conclusion, i am not really happy with where this is all going.
Finalist is obviously driving this towards an architecture where java
programming is central to mmbase development (it's what they do after
all), and mmbase is just one more framework in their stack. I think
mmbase has some properties that make it different from all those (very
nice) j2ee spinoff api's, and i think we should expand on that, in
stead of marginalize.
regards,
Ernst
Johannes Verelst wrote:
Hi all,
As some of you know (and probably others don't), I have been busy
together with Nico Klasesn to see if there is a way to create an
"MMBase framework". The reason is simple: many companies have spent
huge amounts of money for custom MMBase implementations, and
components in those implementations are never given back to the
community. One of the reasons is because of the 'lock-in' to their own
framework which was built on top of MMBase.
With many frameworks already in existance, and the need for "generic
components", I looked with Nico at Didactor, the EO site and to
finalist's Karma/CMSC. The result of this session is now a word
document that I attach here (html version also added).
The main suggestion is: don't enforce a "great unified mmbase
framework", but work the other way around: define some interfaces that
frameworks should implement and components must use. That way every
framework can keep its own way of doing things. So, don't enforce
people to use either tree-include or leaf-include, but create an
interface for creating URLs for which the EO will write an
implementation for their framework which generates urls based on
leaf-include.
Next week, on the symposium organized by Jo, I will present this
proposal to parties interested in a mechanism to share components
between parties. Currently it is "my" proposal (together with Nico),
but I would hope it could be "our" proposal. For that I need your
comments, insights and possibly even flamewars :).
Johannes
------------------------------------------------------------------------
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
