Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Upayavira" <uv@upaya.co.uk>
To: cocoon-dev@xml.apache.org
Date: Sat, 28 Jun 2003 16:00:17 +0100
MIME-Version: 1.0
Subject: Re: Link view goodness (Re: residuals of MIME type bug ?)
Message-ID: <3EFDBB91.817.47ED886@localhost>
Priority: normal
In-reply-to: <bdjsd5$ru0$1@main.gmane.org>
References: <20030628015943.GA3194@expresso.localdomain>
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

Nicola Ken, 

> Sorry Jeff, but I don't have time nor energy to dwelve into this
> discussion further. I'm getting a bit tired about it too. Don't get me
> wrong, it's not about you, it's just that sometimes one loses interest
> in some things.

FWIW, I'm pleased that Jeff is prepared to go along with these discussions - I think 
our original discussions only went so far. We got it down to one pass, and were pretty 
happy - we didn't really engage further with what the real consequences of that were, 
and what we potentially lost. And I think because we didn't do this, we haven't brought 
the rest of the Forrest community along with us. But now it is happening, which can 
only be good.

> First of all, all I want is speed and less memory usage. At least the
> same speed we are now getting with the new CLI. If any alternative
> scheme can be devised to get to comparable speed and possibly memory
> usage, I'm *completely* fine with it. IIUC What came out of the
> initial "new CLI" dicussion is that a single pass can be regarded as
> both technically and conceptually better.

I agree entirely.

> Secondly, it seems to me that you are mixing conceptual decisions with
> what are in fact just implementation "details". Things you have
> pointed out, like fixed gatherer position for example, are just fruit
> of the initial implementation, not a thorough and important design
> decision, and thus have still to be improved upon and testes in the
> real world (for us it's Forrest). 

Exactly. And that is the point we are now coming to - we can move the link gathering 
stage where ever we like without slowing down the CLI. In fact, having an explicit one 
will speed things up, as we'll get rid of its use on cocoon: protocol pipelines.

> Finally, the new CLI is a WIP, so I applaud your effort in getting it
> better, so that it does not throw out the baby (link view) with the
> water (3 pass generation). I'm trying to see that in this process also
> the new features of the CLI (one pass gathering) are not thrown out
> themselves in the process of saving the baby ;-)

With the idea of two link gathering transformers, both of which can be placed 
anywhere in a pipeline, one which extracts hrefs and xlinks (as does the current link 
gatherer) and one which consumes a links namespace (which allows complete 
control over your followed links, just like the links view), I think we've got the best of 
both worlds. An empty bath with a baby in it :-)

Regards, Upayavira