From dev-return-73000-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Tue Apr 05 12:40:22 2005 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 52261 invoked from network); 5 Apr 2005 12:40:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Apr 2005 12:40:21 -0000 Received: (qmail 39172 invoked by uid 500); 5 Apr 2005 12:40:15 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 39073 invoked by uid 500); 5 Apr 2005 12:40:15 -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 39027 invoked by uid 99); 5 Apr 2005 12:40:14 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from lakermmtao11.cox.net (HELO lakermmtao11.cox.net) (68.230.240.28) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 05 Apr 2005 05:40:13 -0700 Received: from [192.168.0.100] (really [68.100.13.69]) by lakermmtao11.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050405124009.VLUI29670.lakermmtao11.cox.net@[192.168.0.100]> for ; Tue, 5 Apr 2005 08:40:09 -0400 Message-ID: <42528727.2000301@reverycodes.com> Date: Tue, 05 Apr 2005 08:40:07 -0400 From: Vadim Gritsenko User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] The block protocol References: <42444CFF.4020807@yahoo.de> <42446062.8000404@nada.kth.se> <424529B7.2020409@yahoo.de> <4245512C.3000107@nada.kth.se> <4248F241.2050503@apache.org> <4249437A.80600@nada.kth.se> <424980CB.4030708@apache.org> <42499D1D.6000104@nada.kth.se> <4249ED2C.8060408@apache.org> <424A84B7.1000008@nada.kth.se> <424AD336.5090804@apache.org> <145538d32be941a4d4a0cdaf34368a84@betaversion.org> <42515C8B.50200@nada.kth.se> <27d16f2cfcb013d36d2df2f35f6ac93e@betaversion.org> <42517468.4040305@nada.kth.se> <4251B18F.80608@nada.kth.se> <4251E699.7050901@reverycodes.com> <42525111.70005@nada.kth.se> In-Reply-To: <42525111.70005@nada.kth.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Daniel Fagerstrom wrote: > Vadim Gritsenko wrote: > >> Daniel Fagerstrom wrote: >> >>> Inter block access >>> ------------------ >>> >>> An URI to another block "skin" e.g. looks like: >>> >>> block:skin:/foo/bar >>> >>> the BlockManager >> >> >> You probably meant here "BlocksManager" > > > No I meant BlockManager. In my discussion I assumed that a BlockManager > is responsible for the information within a block element in the wiring > (http://wiki.apache.org/cocoon/BlocksWiring) and that the BlocksManager > "correspond" to the blocks element. So from this the BlocksManager only > know the URI that identifies the block. The mapping from a short name to > the URI > > skin -> http://mycompany.com/skins/corporate/34.3.345 > > is only known localy whithin a BlockManager. Yes, you are right. See my prev email about portal / profile block: portal knows which profile it wants (URI), and BlocksManager can resolve block instance using URI. > The situation is AFAIU > analoguos with the relation between a namespace URI and a namespace > prefix. Where the URI is a universal identifier and the prefix works as > a identifier within the document. In the same way the blocks URI is a > universal identifier of the block while the short name only identifies > it whithin a certain block and the wiring for the block is like a > namespace declaration. Different blocks can access the same block with > different short names. Yep >>> resolves it by looking up "skin" in the wiring info for the block >>> (http://wiki.apache.org/cocoon/BlocksWiring) and find the mapping: >>> >>> skin -> http://mycompany.com/skins/corporate/34.3.345 Now we are on the same page. So BlockManager (or something else on its behalf - like Wiring) looks up URI by the short name. > The BlockManagers could be wired to get direct access to each other > during start up. In that case we don't need a global identifier during > execution. I prefered to make all communication between the blocks > proxied by the BlocksManager in the interest of isolation. Yes, once URI known, BlockManager should ask for other block instance from BlocksManager (which might be as simple as this.manager.lookup()). >>> in the connection section, where >>> "http://mycompany.com/skins/corporate/34.3.345" uniquely identifies >>> the specific skin implementation that has been choosen at deploy time. >>> >>> >>> Is the URI unique enough? What if I want several variants of the skin >>> that has different deployment parameters and implementations of >>> theire connections. >> >> >> IIRC, URI is generated, at that time uniqueness is guaranteed by >> BlocksManager (who created the URI). > > > From http://wiki.apache.org/cocoon/BlockIdentification, I get the > impression that URI is "universal" rather than locally generated at > deploy time. Yes, my recall was wrong :-) >>> >>> >>> Interesting enough, IIUC, blocks are only accessible through the >>> block protocol from other blocks, >> >> >> No; IMHO they are all available through BlocksManager. > > > They are, but AFAICS they have no common short name that could be used > outside blocks, and it is the short name that is used by the block > protocol. Which is resolved to URI which can be used to get a block from BlocksManager as described above. > This could be solved by considering the main sitemap being part of a > block as well and have a (possibly optional) block descriptor for it. > Then the blocks would have a short name from the main sitemap as well. I thought about it... If there is a root block, then there will be *no* root sitemap. As I see it, either you deploy root block (new behaviour), or you have root sitemap (old one) which then can mount blocks as needed. Vadim