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.
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.
I totally agree. So standardizing builders is not the way to liberate an
existing application. On the other hand, if you already have the
functionality in a different implementation you don't need the
'standardized' one (unless you want to use other standardized
components). That is a price to pay for sure, but the same problems will
arise when you start converting applications to the mmbase container.
But data migration is definitely one of the holes in the mmbase tool stack..
conclusion: an integrated component system will work best for new
developments.
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.
I can be happy about that. Finalist is a strong development potential
for mmbase, and it needs that.
I do am afraid I led this discussion off topic a bit, but that was why i
did not comment to the individual points of Johannes' mail in the first
place. For me this is a bit of an opportunity to talk about mmbase, and
to find out about what others think and do. I think it is a nesecary
step in the process of developing something like the proposed component
structure
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
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
