Michael Wechner wrote:
[...]
The major problem of Lenya 1.4 is that Lenya forces you to accept a
specific
data structure
This is not true. You can implement custom NodeFactory classes to
support arbitrary storage facilities. The current refactoring has the
goal to make it clearer how to extend the core with custom functionality.
which doesn't make sense, because it's a lock-in and totally
unecessary, because if one separates the navigation properly from the
data storage
with a good data abstraction layer in between, then it's no problem at all.
Then please come up with this good data abstraction layer. I already
proposed an API draft, and I'm trying to bend the existing code slowly
in this direction (separate the data access API from the actual
implementation and allow different implementations).
When I started Lenya some years ago that was one of my major goals and I
still think it's one of the most important things re content management,
because it means
one can share information with other applications, build on content
repositories of
other applications (e.g. DSpace) and no content migration is necessary
anymore.
IMO the maintenance burden of allowing custom persistence layer
implementations is very high, but nevertheless I'm still working in
this direction.
This means you don't have to worry about backwards compatibility anymore
re content.
I don't understand this implication ...
IIUC you mean that custom persistence layer implementations should be
supported (even depending on the resource type, though I don't yet
fully understand how this can be achieved if the meta data are stored
in a resource-type specific repository - isn't this a chicken-and-egg
problem again?).
Re the rest of Lenya I can tell you one thing for sure: There will
always be changes. So one has to think how to live with that without
breaking backwards compatibility. There are several ways to deal with
this, e.g.
- deprecation (instead just removing stuff)
+1 in stable branches
-1 in trunk because it unacceptably slows down development
- delegation
Big +1 (the current refactoring showed that we use too much inheritance,
I'm trying to reduce this)
- discussing/announcing changes before actually doing them
Well, that depends on the change.
I agree that I should have announced the API changes, even if the
interface was deprecated, and the change affecting the content.
- madatory migration tools in the case of breaking backwards compatibility.
+1 in stable branches
-1 in trunk (see above)
Unfortunately I don't see this happening currently within this community
and
the reason I think this is not happening is because some of the core
developers
are either not using Lenya in production or are considering it as their
private toy.
IMO this is a wrong conclusion. I think that the trunk development
should be very lively, and that a release should be done at the first
reasonable moment. The still lacking 1.4 release is practically
unacceptable, though one reason for the delay is certainly my ambition
to keep on improving it. But if we close the 1.2 branch when 1.4 is
released, many changes should be postponed to 1.6.
This might sound harsh, but I cannot explain it otherwise that so little
respect is being shown re people who actually use Lenya and I believe
that this behaviour is
destroying the user base completely.
I agree to Angelo Turetta. The problem is that people started using
1.4 before a release was done.
On the other hand I have to admit that I don't understand why not more
users complain about this big time.
> Either there are none,
I guess this is the case, and I guess it's because there's no release yet.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
