Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E476696.6010504@apache.org>
Date: Mon, 10 Feb 2003 09:45:10 +0100
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [PROPOSAL] Cocoon Science Fiction
References: <200302092147.51460.e9625392@student.tuwien.ac.at>
In-Reply-To: <200302092147.51460.e9625392@student.tuwien.ac.at>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Andreas Hochsteger wrote, On 09/02/2003 21.47:
> Hi Cocooners!
> 
> Sorry for this (very) long proposal below, but I think it's definitely worth a 
> read. If not, at least you can give me some feedback about your opinion ;-)

First of all, let me give you my compliments for a well thought-out and 
written RT.

Second, I will try to reply in a more short form ;-) , so please do add 
things that I left out.

- blocks

  blocks will/should be reusable pipelines, in a way similar to what
  you envision.

- data formats

  This was discussed already when Cocoon was being designed, and
  the result is that the sitemap does not check for consisency
  of what it is given. This "feature" has never really been a
  problem IMHO, so I'd be reluctant to introduce this concept
  strongly in the sitemap. A simple validation-transformer in
  the right places should suffice.

- binary data

  There you are :-)
  Using Cocoon for binary data transformation is easier than many
  may think. Change our pipeline implementation to pipe the
  result of a reader one to another, and and it's done. (sort of ;-)

  I have been investigating such a system with Morphos.
   - description:
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons-sandbox/morphos/src/java/org/apache/commons/morphos/package.html?rev=HEAD&content-type=text/html
   - code:
     http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/morphos/

  I would like to move the effort here, if others agree.
  It would go in the scratchpad,
  <hint> or in a brand-new "sandbox" </hint>


- branches

  This has been proposed too and strongly IIRC rejected by
  some as FS (flexibility syndrome). This is true for publishing,
  a lot less in the flexible transformation engine you envision.
  I'd keep this last in the list ;-)

- protocol indipendence

  We have already, as you say, an environment. What you propose is
  to use the same Cocooc instance as a back-end to multiple
  simultaneous protocol frontends (mail, http, etc).
  Cocoon is a transformation system, so it should not really itself
  bother about how to get the data, ie it's not a server.
  Would it be a compelling use-case to use a single Cocoon instance
  with multiple protocols? Not sure, I don't have the need now...


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org