Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Message-ID: <3E5580A8.9020607@wyona.org>
Date: Fri, 21 Feb 2003 02:28:08 +0100
From: Michael Wechner <michael.wechner@wyona.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
MIME-Version: 1.0
To: general@incubator.apache.org
CC: cocoon-dev@xml.apache.org
Subject: Re: Proposal for Lenya
References: <3E539C3C.5000106@wyona.org> <3E54CBE1.7030605@outerthought.org>
In-Reply-To: <3E54CBE1.7030605@outerthought.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Steven Noels wrote:
> Michael Wechner wrote:
> 
>> Dear Incubator List
>>
>> Here's our proposal for _Lenya_ (plz see below), a Content Management 
>> System based on Cocoon. The proposal can also be viewed as HTML at:
> 
> 
> [cc'ed to cocoon-dev where Cocoon PMC lives, which will ultimatelly 
> decide whether Lenya can become a Cocoon sub-project - read 
> http://www.wyona.org/lenya.html for background info]
> 
> Some remarks and initial thoughts, mostly based on [BT] (belly 
> thoughts), so please don't take too serious or feel offended:

No problem, thanks for starting the discussion.

> 
> * IMHO, the ASF as a whole has a focus on generic 'lower-level' 
> frameworks created to build a variety of applications or serve as a 
> deployment container. I've been 'quite interested' (= understatement) in 
> CMS frameworks for a long time already, but find it a domain where _one_ 
> design doesn't necessarily fit _many_ use cases. I'm not saying the 
> meta-generic framework which will address all use cases exists (or could 
> be created), I'm just afraid the early design of Lenya might be based on 
> a set of assumptions which will be hard to reverse/refactor when fresh 
> blood comes into the project and new ideas arise. When I see 
> "disentangle cms & publications", I get worried.

What does worry you, or better how do read/interpret this sentence?

We mean by this sentence, that we currently have a directory called 
"pubs" where all the (sample) publications are located:

                    pubs
                      |
   ----------------------------------------------- ....
   |             |           |       |
computerworld  oscom       docs    unipublic      .....

and they are mounted "automatically" by */** ,where the first
star is the publication id (e.g. oscom).

The problem is that we have accumulated quite a lot of sample 
publications within this directory and they are all within one
CVS module.

So, all we like to do is to refactor the build process a little bit, 
such that you can declare your pubs path within build.properties for 
instance and that we don't have to ship all sample publications within
one CVS module, but rather have one or two (well maintained) sample 
publications within one CVS module and all the others within a 
scratchpad module for instance, or maybe provided by a third party.
Well, that's it for the moment.


Another reason to do it this way is that:
Let's say you like the publication oscom.org. This means you might 
download it from oscom.org, put it into the directory "pubs", change
the layout et voila you have a publication with the same information 
architecture, the same document types and the same content management
functionalities, but with your own layout.
And you just had to put it into the "pubs" directory

Well, that's one scenario. Another scenario is certainly that
somebody built a website based on Cocoon and wants to make it manageable
by Lenya. That's a bit harder. We have developed some strategies to do
that for instance by defining a Cocoon view "xhtml4lenya", but still 
it's much more work than by customizing an existing instance of a
certain publication type, which is based on the Lenya (framework resp. API).

So, to conclude, I think you could say,that Lenya itself is not a 
ready-to-deployed solution, but really a framework, which is extending 
and based on other frameworks (Cocoon, Slide, ...) (just as Stefano 
decribes it), but the publications can be (but don't have to) 
turn-key-solutions.

In the end you sell it to the customer as a CMS resp. a Box ;-)

> 
> * A sh*tload of (even Cocoon-based) (half-baked) CMS solutions exist 
> already, which might or might not be willing to join ASF in the future. 
> What will happen if Lenya (nice name BTW) comes and claims that area? 
> Will it be the reference ASF CMS tool? Can CMS be considered an area 
> where the ASF wants to operate in, like Zope (CMF) is...? Or do we stick 
> to supporting technology like servlet containers, http stacks, build 
> tools ... I know there is no policy at ASF that states only one CMS 
> project can exist under the ASF umbrella, but still there is only one 
> JetSpeed, one Tomcat, one Cocoon, etc etc - I hope my point is clear.
> 
> * from what I read here [http://www.wyona.org/roadmap.html#1.0], there 
> is extensive refactoring planned _before_ reaching 1.0, yet this is 
> envisioned to be done as an incubating ASF (Cocoon sub-) project. I am 
> wondering whether it wouldn't be better if this high-impact stuff is 
> done before being moved to Apache

We are currently refactoring a lot of stuff to help developers jump 
start into Lenya (which means dead code removal, simplifying directory 
structures, etc.), but not to set/define a totally ego-centric direction.

Of course we have our ideas, but we really want that others are bringing 
in and are realising their fresh ideas.


  (it also sounds a bit like the Lenya
> people take the move to ASF as a given, which might perhaps be a bit too 
> premature).

Please apologize if it sounds like that. But we really don't take it as 
given.


> 
> * reviewing the archived commit messages, I wonder whether the proposed 
> list of initial committers reflects reality, or that the list has been 
> expanded so that we won't have the suspicion it is mainly one 
> company/group working on the codebase (as is the case with 
> xreporter.cocoondev.org right now).

No, all of them (http://www.wyona.org/acknowledgements.html) really 
contributed and committed to the CMS, but it's true, that the most 
active committers are currently working at Wyona.

BTW: I just realized that the link to the mailing lists is outdated. The
correct one is http://wyona.org/cgi-bin/mailman/listinfo
(we just changed our mail server the day before yesterday)

The CMS project was never really owned by the company Wyona, but by the
non-profit organization wyona.org (under Swiss Law),which has very 
similar bylaws just as ASF. The reason was to guarantee that the project
is always Open Source and also to guarantee Open Development, no matter 
what could happen to the company Wyona.

Now, we made one mistake (beside others) and that is that we called the
project Wyona. At the very beginning I called it XPS (Extensible 
Publishing System), but the name XPS is registered by Hewlett-Packard 
(and others) and I also thought it was a too technical name. So we 
renamed it to Wyona CMS (I have to admit one reason was also 
cross-branding, just as we learned from Zope did vice versa. Their 
company name used to be Digital Creations).

So, I think the perception of many developers is/was that Wyona CMS is 
owned by the company Wyona, although that is not true
and I think some people didn't join just because of that perception.
But it's perfectly understandable.


> 
> * Xopus has recently had some troubles w.r.t. its licensing policy 
> (open, not open, etc...) Are these things effectively solved right now? 
> What part of Xopus will be inside Lenya CVS?

We are currently using Xopus2.0.0.0 and we will integrate Xopus2.0.0.8,
where both of them are under the Apache License.

It would certainly be great to have the newest version as OS, but it's 
hard to tell at the moment if that will happen.

> 
> As I said, these are 'just remarks'. The fact I'm posting them means I 
> actually care about this proposal, in a positive sense.

I hope I was able to clarify your remarks/questions.

Thanks

Michael
> 
> Best regards,
> 
> </Steven>