On May 22, 2006, at 1:21 PM, Johannes Verelst wrote:
Hi all,
Hi,
I am kinda unsure on how to best react to this document but i feel
its important that
every developer reads and if possible provide some feedback on it
since it gives us
a idea of how much support there is for the ideas presented in it.
Let me be clear, im 80% possitive about the direction you have taken
it does as you
outlined leave alot of areas open for discusion and i guess that is
needed next but
it also confirms clear areas where with a little tuning we are ready
for a component
system we can all share.
Please see my following comments as a first reaction based on the
document
and a little interaction on the #mmbase irc channel.
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.
It also means we changed (as discussed at the developers meetings)
our worldview/product
view. Sofar we only tried to enforce a shared core (stopping at the
bridge) the last 6 years have
shown that that doesn't result in alot of sharing since most of the
software created in the MMBase
eco system is above the bridge. By adding a second layer (working
title MMBase Framework) we hope
to fix that and see more people share components.
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.
I agree with the don't enforce one unified way and support the direction
you have taken but it does leave us with a problem. It leaves us with a
'hole' in the programming stack unless you pick one of the frameworks.
This would mean we need some kind of reference/testing implementation
included in the mmbase distrobution. Either one of the known frameworks
has to turned into this reference or we need to make a small testing
implementation correct ?. As i understand it your own view is that
the last
option is your personal pick ?
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 :).
I propose you turn this into a MMBase project as soon as possible and
use the
document as a starting point. I also feel that the sooner we can have
a project
meeting on this the better.
Ill comment on the document in a seperate mail not to have to many
issues in one.
Daniel.
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
