Return-Path: 
 <dev-return-77128-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 27455 invoked from network); 17 Aug 2005 15:46:32 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 17 Aug 2005 15:46:32 -0000
Received: (qmail 95385 invoked by uid 500); 17 Aug 2005 15:46:30 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 95322 invoked by uid 500); 17 Aug 2005 15:46:29 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 95309 invoked by uid 99); 17 Aug 2005 15:46:29 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Aug 2005 08:46:29 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [68.230.240.35] (HELO eastrmmtao04.cox.net) (68.230.240.35)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Aug 2005 08:46:48 -0700
Received: from [192.168.0.100] (really [70.179.64.83])
          by eastrmmtao04.cox.net
          (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP
          id <20050817154626.HSZL27901.eastrmmtao04.cox.net@[192.168.0.100]>
          for <dev@cocoon.apache.org>; Wed, 17 Aug 2005 11:46:26 -0400
Message-ID: <43035BD0.6000805@reverycodes.com>
Date: Wed, 17 Aug 2005 11:46:24 -0400
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Standardizing resources in jars (was Re: [Proposal] Switch to
 Maven NOW)
References: <43031AFF.4010507@apache.org> <43031F85.70207@mobilebox.pl>
 <430327ED.4040201@apache.org> <430330E7.3090804@nada.kth.se>
 <43033BA8.6010509@apache.org> <43034537.1010908@nada.kth.se>
 <43034F76.5080601@apache.org>
In-Reply-To: <43034F76.5080601@apache.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
> 
>> Sylvain Wallez wrote:

<snip/>

> So the "resource:" protocol will behave with OSGi just as it behaves 
> otherwise, with the restriction that the search path is restricted to 
> the bundle's dependencies.

Totally makes sense (*).


>>>> Maybe we could have an own bundle protocol 
>>>> (through the source mechanism), that works like the OSGi bundle 
>>>> protocol but have symbolic block names instead of bundle numbers.
>>>
>>> Something like "block-resource://org.apache.cocoon.forms/..." ?

First problem: block name is missing. You probably meant:

   block:myforms:resource://org.apache.cocoon.forms/

(resolve resource: in the context of the block). But...


>>> This can be implemented today in 2.1.x by having this protocol 
>>> delegating to "resource:"
>>
>> That would be one possibility, question is if we want direct access to 
>> blocks.

Probably not. Above can be achieved using regualar block protocol, and an entry 
in the block's sitemap to export resources:

   block:myforms:resources/css/forms.css

Whereas myforms' sitemap will have match for resources/**/*.css
But...

<snip/>

> In the meantime, we can consider the access through 
> "resource:" as an transition step between copy/paste in each application 
> and block-powered services.

Given the fact that resource: protocol still works as expected with 'real 
blocks' (See (*) above), conclusion is that simple sitemap snippet:

   <map:read src="resource://org/apache/cocoon/forms/resources/css/forms.css"/>

is enough, and no 'fancy' block protocol is necessary.


> <snip/>
> 
>> The idea for blocks is that blocks that contain public URLs are 
>> mounted at deploy time at a some root URL, then the URL revriting 
>> transformer translates internal use of symbolic block names to the 
>> public exported ones.

Why would anyone internally use any block: URIs? This should be totally 
unnecessary: you can either use relative URIs, or construct absolute by passing 
sitemap prefix into the xslt - same as we do in existing samples.

Vadim