Return-Path: Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 69463 invoked by uid 500); 16 Jul 2003 17:14:04 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 69449 invoked from network); 16 Jul 2003 17:14:04 -0000 Received: from jhuml4.jhu.edu (128.220.2.67) by daedalus.apache.org with SMTP; 16 Jul 2003 17:14:04 -0000 Received: from jhuml4.jhu.edu (jhuml4.jhu.edu [128.220.2.67]) by jhuml4.jhu.edu (PMDF V6.1 #47563) with SMTP id <0HI400NBENVE1T@jhuml4.jhu.edu> for dev@cocoon.apache.org; Wed, 16 Jul 2003 13:14:05 -0400 (EDT) Received: from jhuml4.jhu.edu ([128.220.2.67]) by jhuml4.jhu.edu (SAVSMTP 3.1.0.29) with SMTP id M2003071613140500028 for ; Wed, 16 Jul 2003 13:14:05 -0400 Received: from pirouline.sts.jhu.edu (pirouline.sts.jhu.edu [128.220.31.194]) by jhuml4.jhu.edu (PMDF V6.1 #47563) with ESMTP id <0HI400NBZNVH1T@jhuml4.jhu.edu> for dev@cocoon.apache.org; Wed, 16 Jul 2003 13:14:05 -0400 (EDT) Received: (from phantom@localhost) by pirouline.sts.jhu.edu (8.11.6/8.11.6) id h6GHE4x32417 for dev@cocoon.apache.org; Wed, 16 Jul 2003 13:14:04 -0400 Date: Wed, 16 Jul 2003 13:14:04 -0400 From: Tim Myers Subject: Re: [RT] The perfect repository might be just under your eyes In-reply-to: <"from colle006"@umn.edu> To: dev@cocoon.apache.org Message-id: <20030716131404.A32320@pirouline.sts.jhu.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5.1i References: <61A2F881-B6FF-11D7-A769-000393D2CB02@apache.org> <3F1466A0.5080304@umn.edu> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi guys. > Imagine having an XSL processor in the kernel: I don't think you are asking for xsl in the kernel. What you are asking for is the cocoon shell: cocoonsh. Also, though it would be theoretically possible to implement an xml aware filesystem-- Some experience (google search xdelta xdfs) has shown that a usermode filesystem extension (i.e. cocoonfs) may be more convenient. And if you want that mapped to a mountable filesystem in linux, use a thing like podfuk . The most useful thing the coda project has come up with is a simple filesystem hook into linux: /dev/coda. Podfuk is a great usecase. The possibilities are amazing. Tim > You could "execute" .xsl files, bypassing having to run a processor manually. > > prompt$ page2html.xsl < input.xml > output.html > > Borrowing the pipeline concept from Cocoon: > > prompt$ cat input.xml | page2foo.xsl | foo2bar.xsl | bar2html.xsl > output.html > > One could even invent files which are actually transformation pipelines -- ones which you might not > be able to directly edit (or maybe be able to edit a transformation in the middle): > > prompt$ make-virtual-file-pipeline virtual.xml --generator=input.xml > --tranformers=page2foo.xsl;foo2html.xsl --serialize=text/xml > > Now you can just go > > prompt$ cat virtual.xml > > And get the output of the pipeline defined above, which you can then link to other pipelines, etc. > > It's no wonder that this all fits in very well with what Cocoon does, since Cocoon is patterned > after this concept. I'm sure if I stew on this concept enough I'll come up with more ideas and uses. > > Tony >