Hello Michiel,
The below is all very focused on code rhings. I am not sure that we need
a CoreNode and CoreNodeManager and that we have to drop MMObjectNode or
MMObjectBuilder. I rather would take a step back and observe MMBase from
a distance. There are many parts in MMbase which are bloated with things
that don't match the initial goal.
The bridge is a very good example. It was added on top of the core to
streamline many templating languages, but now it takes over some of the
features the core should do. This is okay, but then we have to redefine
what the responsibilities are of these parts.
Another thing I don't like is the changes set and oldValues in
MMObjectNode. All users are sharing these collections and can commit the
MMObjectNode. The TemporaryNodeManager and the bridge are doing some
"magic stuff" to prevent some of the issues which arise. I am vague on
this, because I have never figured out how it exactly works and that is
the real issue.
Another one is the difference between MMObjectNodes, VirtualNodes and
ClusterNodes. How can VirtualNode extend MMObjectNode and not be
persistable? It inherits a feature and removes it? It is also not clear
in the bridge which type of node (MMObjectNode, ClusterNode) is returned
in lists, because they are both wrapped by a BasicNode. This gives a lot
of confusion for application developers.
The above are not examples of things that are wrong, but things that
show we need more then the old concepts are providing. We should analyze
them and design a solution which includes them in a nice way.
When we do a step back and view at the "ugly" things then we should also
look at other frameworks how they handle them. MMBase is a persistency
layer with additional services and features. Hibernate, EJB3 and jsr-170
have some concepts which might be appliable to MMBase.
For example, Hibernate makes a clear distinction between POJO's and
RowSets. A POJO is our MMObjectNode and the ClusterNode matches more or
less with a RowSet. We also could make that distinction instead of
inheritance?
Another example is the workspace and session concept of jsr-170. You
login to the repository providing credentials and a workspace name. This
all sound very similar as the ContextProvider and cloud login. jsr-170
returns a session. MMBase returns a cloud. The only difference is that
we don't have a well defined concept for what a cloud is. When I try to
explain the mmbase cloud concept I usually use the vague phrase: 'it is
almost like .., but then with ... and without ...'
IOW, I am not going to work on something which is anticipating what we
need in a good architecture. I would love to work on something which
promises me a good architecture. When you know what you are going to
build then it is easier to refactor in steps.
I also doubt that our end-users (the application developers) would wait
for all the features you mention for 1.9. I think they rather like to
see a less confusing architecture.
Regards,
Nico
Michiel Meeuwissen wrote:
Since 1.8.0 is out, we can now think about what we can do for upcoming
releases.
If I may start making suggestions:
1.8.x:
- bugfixes (also when related to performance only)
- loose ends on datatypes (XML presentation and javascript,
commons-validator wrapper, LIST db type?)
- loose ends on applications and contributions.
1.9.0
- dropping support for java 1.4, dropping backport-concurrent,
using other java 1.5 features in the code. Evaluate what we must do
with things like 'NodeList' (should it not become List<Node>?)
- 1.8 has made a start with a new org.mmbase.core package
We must discuss how we progress with this. CoreField suggest that
also CoreNode, CoreNodeManager may follow. We may introduce these
in 1.9 already.
- Changes necessary for the upcoming application/portlet
framework. E.g. to accomodate versioning, workflow and
application-packaging features more easily.
- 1.8.0 is shipped with succeeding junit test-cases.
1.9 must be shipped with standardized bench-marks for performance of
core, bridge, taglib etc. I feel it is a problem that must be
addressed that we don't well perceive performance regressions or
improvements.
Something like that seems to be enough for a new major release. It
should not take over 2 years again. I'd say we must strive to a release
of 1.9 in 2006.
And after that:
2.0 (yeah! core2, finally!, after so many years ...)
- Completing of the 'code clean up' (optimization project)
- Dropping MMObjectBuilder MMObjectNode, in favour of more bridge
like interfaces all around (as we may have anticipated in 1.9 by
filling org.mmbase.core..).
- ....
- ...
Please, comment and contribute.
Greetings,
Michiel
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
