Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F97CC8A.3040102@apache.org>
Date: Thu, 23 Oct 2003 14:41:46 +0200
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.5) Gecko/20031013 Thunderbird/0.3
MIME-Version: 1.0
To: dev@cocoon.apache.org,  forrest-dev@xml.apache.org,
 lenya-dev@cocoon.apache.org
CC: server-dev@james.apache.org
Subject: [proposal] Doco
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

First of all, sorry for the massive cross-post, but I think it is going 
to be a great opportunity for all the communities involved to show off 
their potentials with the apache infrastructure.

The proposal is about the creation of a content management system for 
apache projects, codenamed "Doco"

The features will be:

  1) super-easy editing (should satisfy wiki lovers)
  2) minimal, efficient and secure workflow (should satisfy board@ 
security concerns)
  3) should allow the creation of static content (should satisfy 
infrastructure@ and mirror@ concerns)
  4) should not be a distributed product (should avoid sensations of 
forking from existing projects)
  5) should reuse more than reinvent
  6) should come up with structured XML content well organized in a 
repository

Here is my proposed architecture:

   static site <--- frontend/staging <--- repository <--- backend

Static site is httpd running on minotaur (the main ASF web)

Frontend/staging will be Forrest. The idea, in order to satify 
intrastructure@ concerns is

  1) forrest runs on top of the repository and generates a staged 
version of the web site (not on minotaur!)

  2) a cron job on minotaur will

    a) download the entire site from the staging area (using rsync, wget 
or similar tools)
    b) commit it on the "site" module CVS
    c) move it on the public site folder

The reason for such an "inverted" architecture is to avoid having an SSH 
access directly from the machine that runs forrestbot. This guarantees 
*COMPLETE* isolation of minotaur from the rest of the system. There is 
*NO* way for somebody to hack into any parts of doco and obtain access 
to minotaur.

The reason for committing a copy on CVS is to allow infrastructure@ to 
have a fresh copy of the web site in case something happens and Doco is 
down. [they have expressed concerns about this]

Repository will be Subversion (for now, in the future, the idea is to 
move into JSR-170-based repository, but this will take a while)

Backend will be a lenya publication. It will incorporates Linotype as a 
Cocoon Form widget and wiki-syntax/wysiwig cross-editing capabilities. 
The workflow will be both web and/or email driven.

Here is a tentative workflow:

  1) everybody can edit a page and submit the changes. the pages on the 
main site will have a link that connects to the pages on the backend 
(which will be probably hosted on another machine, either nagoya or moof)

  2) if a user can log in (doco committer), no workflow takes place and 
changes to directly into the repository. [the repository will generate 
diffs for changes and send email to the "docs" list for public oversight]

  3) if a user cannot log in, workflow starts:

       a) the changes are stored into a local spool
       b) email is sent to the 'doco committer' list, this is going to 
be a private list
       c) the email will have "reply-to" set to the "allow" action and a 
continuation ID. and will have the CC: header set to "reject" with the 
continuation ID. So, by "replying" to the email
       d) by hitting "reply", the workflow will approuve the changes
       e) by hitting "reply to all", the workflow will reject them with 
no further action

The idea is to use the Lenya workflow manager in coordination with 
James. Basically:

  1) lenya sends an email to an account managed by james
  2) this account is mapped to a mailing list mailet that will dispatch 
this message to the people subscribed
  3) the "reply-to" fields of the email sent will be mapped to another 
account handled by james
  4) this other account is mapped to another mailet that will parse the 
"email address", extract the continuation ID, understand the action to 
take and trigger an HTTP request to lenya with the action and 
continuation ID that will re-initiate the workflow. [the message of the 
mail is discarded]


TODO list:

1) create a lenya publication that uses linotype (the 'doco' publication)
3) configure doco with the workflow described above and write the 
necessary java classes that drive it
4) write the HTTP-triggering mailet (reuse the mail list mailet in james)
5) write the subversion implementation of the "repository" component 
[this will be sent back to the "repository" block in cocoon]
6) write the cron scripts for minotaur
7) install lenya, james, forrest and forrestbot on Moof.

I propose the creation of a new CVS module called "cocoon-doco" to host 
the scripts, installation instructions and doco-specific code.

I also propose the discussions to take place on lenya-dev, given that 
Lenya is the community focused on content management. Interested people 
are invited to join lenya-dev@cocoon.apache.org.

[in case of community-oriented you reply to this email, please, keep all 
listed cross-posted, but in case of technical discussions, please, let's 
move it over to lenya-dev to avoid mailbombing people that don't really 
care]

Awaiting for your comments.

-- 
Stefano.