Return-Path: 
 <cocoon-dev-return-25300-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 33221 invoked by uid 500); 8 Apr 2002 11:02:08 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 33210 invoked from network); 8 Apr 2002 11:02:08 -0000
X-Antivirus-Data: Virus data file v4189 created Mar 06 2002
Message-ID: <3CB177AA.110D82C4@apache.org>
Date: Mon, 08 Apr 2002 12:57:46 +0200
From: Stefano Mazzocchi <stefano@apache.org>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [status & RT] design challenges
References: <3CADD659.F9A928AF@apache.org>
 <002901c1dcc5$5b51a570$670004c0@PC103> <3CAE1044.2B8D1BA6@apache.org>
 <01b101c1dd27$5ecc60c0$0c91fea9@galina>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Ivelin Ivanov wrote:
> 
> <snip/>
> 
> > So, if we have an error in a transformer that writes on a database, we
> > don't have to 'write this information inside the pipeline' in order for
> > a subsequent selector to get it and behave consequently.
> 
> If my intuition is remotely correct I would think that in the near future,
> people will often want to
> plug in the pipe web services calls (via SOAP transformer) instead of direct
> calls to custom Java classes (in the form of Transformers or Actions). This
> will allow them to reuse WS interfaces for both human computer interaction
> and automatic calls. Will save them testing time, etc.
> 
> Let's take a sample pipeline:
> 
> <pipeline>
>   <action desc="Handle Last Page of a Form Wizard: populate and validate
> last phase"/>
>   <transformer type="castor|jaxb|betwix|?" desc="Make the output of the
> action available in the request"/>
>   <transformer type="soap" src="http://some/WebSerice/target" desc="Make a
> SOAP call sending the SAX input as body">
>   <select type="xpath">
>      <when test="/envelope/header/error/500"/>
>         <transform desc="show Bugs Bunny. WS is not availabe!"/>
>      </when>
>      <when test="/envelope/body/purchase/result/complete"/>
>         <transform desc="go to the next stage"/>
>      </when>
>      <when test="/envelope/body/purchase/result/cardDenied"/>
>         <transform desc="go back to the page in the wizard whith the Credit
> Card input fields"/>
>      </when>
>  </select>
> </pipeline>

Ah, yeah, I was thinking about WebDAV as well.... People: if you talk to
the architect of the web they will *all* agree that XML-based protocols
are evil, they are a pretty nice try from Microsoft to steal the HTTP
leadership and move the battle on a more virgin battlefield.

We must be *very* careful down this path, but I see that it would be
stupid to fight this nonsense by imposing functional restrictions on
cocoon (and scare users away).

> There is a clean separation in my mind between xpath selectors and
> transformers .
> The former act as bugzilla moderators. They look at a bug and assign a
> developer to it.
> The latter transform one sort of document (bug) into another (patch).
> 
> >
> > I'm perfectly aware of the fact that components must pass information
> > one another, but, why in hell should they use something so ackword as
> > SAX events to write and XPath queries to read when they can simply do an
> > hashtable lookup?
> 
> Maybe it will never be as fast as a hashmap lookup, but as you said if its
> valuable enough,
> the community will eventually make it sufficiently fast.

This is a good point.
 
> Without putting too much thinking, one simple possible optimization that
> comes to mind is: when the document preceding the selector is cached then
> the selector does not need to evaluate the tests. It'll know the answer.
> So if a web service responds with the same content, i.e. reports that the
> result didn't change, then you can imagine that the selector is going to be
> pretty fast.
> 
> >
> > Do you pipe-aware selector fans see my point?
> 
> I totally support your efforts to challange anything new to the extreme,
> before it makes it in CVS.
> This is one certain way to ensure that Cocoon will not explode before its
> 5th birthday.

Ok, the web service example is a good one: I admit that pipe-aware
selection in this case makes perfect sense because we are *not* in
control of what comes out of the web service and SOAP places everything
(even control metadata) inside the envelope (which is a *big* design
mistake, but we can't change this).

Another example is WebDAV: I'm planning to try to think of a way to add
WebDAV support to resources using views... more or less like Zope does
but in a more transparent way (Zope support for WebDAV is fake: it's
simply a tranport protocol, not a way to handle separate 'inward'
'views' of the resource, as it was supposed to be). Even WebDAV
(expecially DeltaV) pass much metainfo inside the XML stream, being able
to select that would make sense.

Oh god, I'm starting to change my mind too much today :)


-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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