hi dag!
disclaimer: i'm quite new to the lenya project, so my views may not
always be accurate, but i hope to be able to answer some of your questions.
Dag Sverre Seljebotn wrote:
<snip>
And, looking further at repositories, I found the Daisy repo, and
fell in love. Didn't really fall in love with the Daisy Wiki though.
What the Daisy repository provides: - XML repository with
SQL-queriable metadata, versioning, branching, alternative languages
etc., a good ACL system, flat document organisation with seperate
navigation documents, and a good query language for extracting
documents (merging the URI-space information in the document). - The
Daisy project provides a Wiki on top of this, which can't really be
used as a CMS as such. However it is an excellent developer tool for
accessing the repository. - Note: The seperation between the Daisy
repository and the Daisy Wiki is extremely good.
My questions are simple: - Consider what is left of Lenya after
subtracting the repository, access control, and versioning. Is it
worth it trying to fit Lenya on top, or not? - What do people think
of the idea?
i've seen daisy in action, and talked to a daisy core developer, and it
sure is a very impressive product.
but as you say, the wiki on top is problematic if you're looking for a
pretty stringent content management system that will enforce CI and
structure.
the lenya repository has seen huge improvements lately, as did the
access control layer (the latter has gained a very nice UI and neat
features - however, a thorough security audit remains to be done).
andreas and thorsten have invested a lot of work into these components,
and it would certainly be sad to ditch all that, but i really agree with
you that we should have used an existing, proven repository rather than
rolling our own.
btw, i briefly looked at hippo cms, and while i did not much like its
editing capabilities, it has a brilliant repository backend, which is
totally separated from authoring and live serving (did you check it out?).
imho, lenya currently excels at in-place wysiwyg editing and publication
templating. our repository looks ok to me as it is now (except that
maybe some hidden bugs need shaking out), but i'd certainly not be
opposed to adopting something else.
andreas has written some proof-of-concept code using the jackrabbit
repository, but the project has been on the back burner for a while.
the way i see it, the problem with lenya is that we carry some really
crufty legacy issues: the revision management used to be a nightmare,
and has only been cleaned up a month ago, and the area concept has been
a mistake from the very beginning imnsho. we used to have loads of
unclean semantics, cluttered global code and very little separation of
components. the situation we have now is that 1.4 attempts to both clean
up the old stuff and add a lot of good new concepts, and it simply
turned out to be a little too ambitions. whenever you want to clean up
some minor issue, you easily end up rewriting major subsystems...
but the light at the end of the tunnel seems near, and i'm pretty sure
it's not a train.
while i would like to see an externally-developed repository some day, i
think we should now concentrate on getting 1.4.0 out, make 1.4.1 really
nice and polished, win some new users and developers and only then think
about lenya 2.0 issues (of which the repository discussion is certainly
one). there have been many little tweaks to our metadata structure,
storage layout, and indexing schemes lately - it will probably take
another while before we really now what a lenya repository backend
should look like and how to create a really clean abstraction layer. to
deepen our understanding, we need huge production deployments to learn
from, and for that, we need a release asap.
(And, another point I'm not sure about including, since I am in no
right to say it, but I don't seem to be able to hold it back: Since
Lenya seems to suffer from developer shortage, why focus on creating
the repository, versioning, multi-language, access control, and
querying parts?
i agree, but for the reasons stated above, i don't think now is the time
to make the move.
(The Blog publication seems to rebuild its own
specialized querying, for instance)
the blog publication is a really bad example of cheating users into
believing we can do blogs. i think it should go. all it currently does
is show that neither our sitetree browsing nor our repository access
scales very well.
our content repository is document-centric and allows for arbitrary xml.
that's good. blog content is simple and belongs in a database.
my current pet thought is that we should put all our storage into an xml
database such as eXist, keep the current storage structure and gain fast
queries and search operations. but i have not pursued this idea very
far, all i did is tack an *additional* eXist repository onto lenya for
data-centric xml (as opposed to the document-centric stuff that lives in
the lenya repo).
If I'm not wrong it was totally
restructured as late as during 2006...)
yes - that was quite a shock to me as well, as i was in the middle of a
project when it happened, and it set me back for months. but then the
old stuff was soooo ugly that in retrospect i'm glad andreas pushed the
change, although back then i could have eaten him raw :-D
best,
jörn
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
