Daniel Ockeloen wrote:
On May 27, 2006, at 3:08 PM, Nico Klasens wrote:
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
Hai Nico,
Your proposals allowed for both models, Its clear that you and
Finalist have a different view on 'what parts' of MMBase make sense.
Ive tried over the last few replies to define that but you found that
to be too confusing, fine. But clearly here you only point to what
you think MMBase is or should be but its clearly not how we all feel.
I think this discussion should focus on how we can be so damn smart
that we allow both models since we define components that we _demand_
run in all these and can itself be implemented in all ways needed to
match the framework of choice.
Let me be clear for me i expect to use a framework (no idea which)
that will mostly use the taglibs or alteast ideas based on them. I
expect i can abstract many of the heavy work into functions
implemented in java. And i hope and expect that the components i
build or update to become components to be able to run in mine but
also the other (pluto/portlets) frameworks and i expect the same from
all other components that claim to be follow these specs.
What needs to be done is to create a few examples (even if they are
not working examples) of what a component looks like so we can all
check and get a better feeling if they would work for us and fit in
our model(s) of working.
The goals of the soon to be project is to start defining interfaces
above the bridge so for the first time we have a real shot at
creating components that we can share. This is both a techinical
issue and a management issue (the will to share) lets not forget that
upto now (as pointed out by Johannes in the proposal) this was almost
impossible and allmost nothing was shared as a result above the bridge.
Lets stay focussed on these components instead of how MMBase should
be used...
Hello Daniel,
My previous reply was an attempt to scope the issue of components which
we are solving in this thread. Every issue which you solve has a scope.
Every solution should stay in that scope. The issues, which I described
in the reply and solved by mmbase cvs code, are totally different from
the component issues. The scope of these issues are completely different
than the component scope. The taglib solves the issue of rapid and
scripting-like access, but that is not one of the issues described in
the document of Johannes. There are two main issues (with sub-issues) in
the document and they both have a scope.
1 What do we need to define a mmbase component.
This is quiet easy, because the applications module and Didactor are
both examples of this.
2 How can we easily integrate a component in (existing) systems.
this is a lot trickier, but it has a limited scope. We have to make
a list of current existing systems and compare them. Every system solves
a big issue namely the customer requirements. Some of the sub-issues are
solved by mmbase. Others like the templating issue are custom solutions,
because mmbase does not solve those issues.
Ernst writes about a system (you call it a framework) which should also
be able to use components. Some of the issues in that system are solved
by mmbase. In scope is how that system can integrate a component, but
not how that system will implement how a component.is integrated. The
systen of Ernst provides solutions for issues/wishes, but they are again
not the same issues as we are discussing now.
Maybe it is just me, but I just don't understand what the "models" are.
It can't be the way we develop web applications in our organization,
because that is not even on the horizon of the components scope. My
guess is that it is the templating mechanism. The templating mechanism
is not about displaying nodes. It is about how to aggregate html
fragments. This can be done though jsp-includes, leaf/tree-includes,
portals, etc. This is already in the document of Johannes.
My previous email is also the way I view at the software world. Every
piece of software is a solution for an issue someone had. When you know
the issue you also know how big its scope is or should be. I know a lot
of people don't view the software world in this way. As I mentioned in
an earlier email, I am still searching and this is the way I can
understand and decide where to use mmbase jars. And to stir up some
more, most sucessful open source products are clear on which issue they
are solving and what the scope is.
Nico
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
