Andreas Hartmann wrote:
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.
ok. How can this be done? Can you give me a pointer?
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).
I once made a proposal re ResourceTypes, Resources, etc. and using
interfaces for Publishing, Creating , e.g.
XHTMLResource implemets Creatable, Publishable
public void publish()
public void create()
public Source getSource()
...
just as each node has meta, one would also have a resource config for
each node
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.
well, I am convinced a high percentage could be solved by very few such
implementations
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?).
I don't think so. But I guess I just have to implement it to prove that
this is possible.
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
why does it slow 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)
well, it's like eating properly at home such that one will be prepared
eating properly when visiting someone.
Also it makes one realize what a change re breaking things actually means.
And third, when a release is getting close one always needs productive
environments to get things finalized.
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.
how do you define lively? And what is a 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.
it's not just you, it's myself and others as well
But if we close the 1.2 branch when 1.4 is
released,
why should we close 1.2 if there are people willing to fix things?
many changes should be postponed to 1.6.
what changes?
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.
this will always be the case, so we will have to find means to live with
that and as I say above it's not so difficult
to live with that if one follows certain guidelines
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.
you really think there is nobody using Lenya 1.4?! I know quite a few ...
Michi
-- Andreas
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
