Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <3963B226.B0687701@apache.org>
Date: Thu, 06 Jul 2000 00:09:42 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] (hopefully) last sitemap major changes
References: <395CD669.DEC70286@apache.org> <20000705110751.A1835@stimmel.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jonathan Stimmel wrote:
> 
> On Fri, Jun 30, 2000 at 07:18:33PM +0200, Stefano Mazzocchi wrote:
> 
> > Ok, I spent the whole afternoon on this and I'm pretty happy with the
> > results. Please, throw rock at it and let's see how solid this is.
> 
> Now *that's* a sitemap =)

Wow, seems it's gaining fans :)
 
> > 3) increased redirection capabilities
> >
> >  <map:redirect-to uri="..."/>
> >  <map:redirect-to resource="..."/>
> 
> This has probably already been discussed, but are these done
> internally to cocoon, or by actually redirecting the browser?

internal.

External redirection is up to the logic in your components (you'll be
given the ability to add response parameters from all components... but
mostly you'd do from XSP.

> Imagine the following example (lifted from the draft) using
> client-side redirects:
>    <map:match pattern="cocoon/dist/*">
>     <map:choose type="ip-filter">
>      <map:when test="allowsAddress()">
>       <map:redirect-to uri="dist/cocoon/{1}"/>
>      </map:when>
>      <map:otherwise>
>       <map:redirect-to resource="Access refused"/>
>      </map:otherwise>
>     </map:choose>
>    </map:match>
> If the redirect is done client-side, then we have to insure that we
> perform the test a second time when the client returns for the
> new location, otherwise one person with access can distribute an
> unrestricted URL to the whole world.
> 
> On further thought, I guess this is a problem in either case; the
> only secure way of doing this (without replicating tests) is
> to use the <map:redirect-to resource=""/> form. (It might be good
> to give this special mention in the redirect-to documentation; a
> novice (or even not-so novice) administrator could easily lull
> themself into a false sense of security...)

Sorry, I don't understand where the security hole is. Can you elaborate
more on this?
 
> > 6) added the notion of "views" and pipeline "labels".
> 
> Hmmmm... I'm not certain I understand the intent here. It sounds
> almost like a mechanism to implicitly apply <map:choose> and
> <map:resources> (minus the generator) to pipelines. If this is
> accurate, do we necessarily need both views and resources?

No it's much more than this and yes, trust me, you'll need this _a_lot_
in the future.

I even venture to say that Cocoon views will make the XML successful,
otherwise, Cocoon will simply kill TBL ideas of a new web.
 
> > BIG NOTE: I believe this sitemap may result a little "pull" centric,
> 
> True, but isn't that somewhat inherent to the HTTP protocol?

Great point (but it's not an excuse).

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------