Hello Ernst,
The below email makes me believe that your answer on 'What is mmbase?'
is different than mine. This greatly influence how we use it and what we
expect from it.
If I have to answer that question then I like to rephrase the question
to "What issue does MMbase solve?" My answer is the same on both questions
What issue does MMbase solve? I already wrote this in my previous mail.
MMbase solves the domain of a data repository which is backed by a
database. MMbase has many data management features a data repository
requires. Examples of these are: search, notification, access control
and type, object and relationship management. A data respository
consists of a repository engine and an API to interact with the engine.
The engine has to solve every aspect of the issue like storage,
configuration, object model, security, search, events, etc
The mmbase solution for this issue can be found inside the mmbase.jar.
'What is mmbase?' For me, the mmbase.jar and not the full distribution
The community provides additional functionality which makes working with
mmbase easier. Every added piece of functionality solves another issue.
Generic editors - solves the issue of easy access to reporitory data.
Editwizards - solves the issue of user-specific and task-based access of
repository data
Taglib - solves the issue of rapid and scripting-like access to
repository data
Clustering - solves the issue of several system working with the same
repository data
RMMCI - solves the issue of remote access to repository data.
... - ...
MMbase is not a scripting language. A scripting language solves a
different issue. You choose Ruby or Python for a different reason then
you choose for mmbase. The taglib address some of the same aspects of
the scripting language issue. Funny to hear that code obscurity is
easier introduced in a type-safe languauge then in a scripting language.
I always thought it was the other way around. You could create something
which solves the same issue as Ruby on Rails does, but then you are not
solving the same issue as mmbase does.
If you think this way in development then you should ask yourself with
every issue: does mmbase solve this issue. In a lot of cases the answer
is no and there is always another product which will solve it. The cmsc
is a good example. I have content and want to store it somewhere. MMbase
solves this issue for me, because it solves data management. I also want
to create html blocks which are aggregated to one html page. MMbase does
not solve this issue for me. Pluto does solve this. I want to make these
html blocks configurable and store this some where. This is data
management again so MMbase could be used.
Nico
Ernst Bunders wrote:
Nico Klasens wrote:
Hello Ernst,
hello Nico, and all others who have responded to this thread
Let me first say I'm quite happy with this discussion. It is not my
intention to put anybody in the hot seat, but i think it is positive
to get to know each other a bit better in this way, and also perhaps
get a more clear idea about what we are all doing and where the whole
thing is going. 'What is mmbase?' is an unanswered question and that
seems to be one of it's prime features. Still i like to hear from
other people how they look at mmbase, what they see in it and where
they want to take it.
Secondly, let me state I'm not against any kind of development. Mmbase
is flexible enough to support different methods of application. For me
it is important many people use it, which ever way they see fit. This
does not mean i think mmbase is equally suitable for all purposes, on
which more later.
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)
I agree with you. That's why this kind of communication is important.
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.
I am glad to hear that, I guess i stand corrected on this point. I did
get the impression that Finalist was having a tendency to use from
mmbase what it could, and avoid those areas that did not quite do the
trick, and put another api in place to do that (i have seen several
Finalist products that wore lashed together in this fashion). of
course there is nothing wrong with it, as we all have done this at
times, but it seems to me that if there is one party in the mmbase
community that can afford it to drive mmbase development in those
situations where a customer needs a feature that is underdeveloped, it
would seem to be Finalist. We just have not seen an awful lot of this.
So if i can read from your words that Finalist is strengthening it's
commitment towards mmbase, I am ever so happy.
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.
Well, let me elaborate. This is also very much the area of 'what is
mmbase', or my answer to it.
First, I agree java is more like a high-end product and 'deserves'
more complex solutions, that are strong and flexible. But on the other
hand i can not see mmbase as an enterprise component. For that it
lacks, as you point out as well, a clear focus in both purpose and
implementation. On the other hand it has some unique features and
advantages over other api's that all partly overlap it. One of the fun
things of mmbase is it's completeness. It offers a solution for every
step of the way of building content management systems, or web
applications in general.
This, along with it's high configurability makes it an ideal system
for rapid development, if not for a few problems (Henk pointed this
out in his reaction as well)
- there are not enough authoring tools for creating mmbase
applications (builders, wizards, inserting business logic)
- there is not a clear separation between the framework and it's
extension points. Functions is partially addressing this problem.
- you have to use java for more complex business logic than scratching
your bum, which introduces problems like added compile cycle and
perhaps code obscurity (what happens were?).
conclusion: you have to know a hell of a lot about mmbase to be able
to use it successfully, because it fails in the separation of concern
department. It is insufficiently possible to determine different roles
in the development process and boundaries between different layers of
the framework are very weak.
So my idea of strengthening mmbase is addressing those points (because
i think mmbase can be most benefited from in that role). I think that
if those problems could be addressed mmbase could be used by a much
larger group of people, allowing the community to grow, and
development to flourish.
So, about not using the strengths of java: In my picture java is the
language of the framework, and the primary solution for extending it's
functionality. But if you look around at what's happening in the
world, and you see the success of platforms like ruby on rails and
python, and on the other hand the small user base of mmbase, the
difference is striking. In my view these platforms strike an excellent
balance between simplicity and robustness, using convention where
sensible, and lifting the burden of development significantly.
We need a language like java to build the framework and make
structural extensions to it, but we don't need it's complexity to
perform simple tasks. If someone has to work with mmbase for years in
order to be able to do simple thins like extend builders, write
functions, and use the 'natural' extension points of the framework, i
see this as a problem.
conclusion: different technology on different layers geared towards
different roles in the development process.
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
