Re: [RT] The block protocol

2005-04-06 Thread Daniel Fagerstrom
Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: I disagree. You have a world-wide unique identifier (the URI) and a local name in a well isolated context, and a wiring table to glue these together (using the URIs) that's all you need. Consider the following case: One

Re: [RT] The block protocol

2005-04-06 Thread Stefano Mazzocchi
Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: I disagree. You have a world-wide unique identifier (the URI) and a local name in a well isolated context, and a wiring table to glue these together (using the URIs) that's all you need. Consider the following case: One of my applications use a r

Re: [RT] The block protocol

2005-04-06 Thread Daniel Fagerstrom
Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: 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

Re: [RT] The block protocol

2005-04-05 Thread Stefano Mazzocchi
Reinhard Poetz wrote: Vadim Gritsenko wrote: Reinhard Poetz wrote: Ralph Goers wrote: Daniel Fagerstrom wrote: Portal block - requires "MyProfile" that implements "profile" Correction: - Requires implementation of "profile" interface. "profile" is implemented by "MyProfile1",

Re: [RT] The block protocol

2005-04-05 Thread Stefano Mazzocchi
Daniel Fagerstrom wrote: 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" t

Re: [RT] The block protocol

2005-04-05 Thread Reinhard Poetz
Vadim Gritsenko wrote: Reinhard Poetz wrote: Ralph Goers wrote: Daniel Fagerstrom wrote: Portal block - requires "MyProfile" that implements "profile" Correction: - Requires implementation of "profile" interface. "profile" is implemented by "MyProfile1", "MyProfile2", ..., "

Re: [RT] The block protocol

2005-04-05 Thread Vadim Gritsenko
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

Re: [RT] The block protocol

2005-04-05 Thread Vadim Gritsenko
Reinhard Poetz wrote: Ralph Goers wrote: Daniel Fagerstrom wrote: Portal block - requires "MyProfile" that implements "profile" Correction: - Requires implementation of "profile" interface. "profile" is implemented by "MyProfile1", "MyProfile2", ..., "MyProfileN". ..

Re: [RT] The block protocol

2005-04-05 Thread Daniel Fagerstrom
Ralph Goers wrote: Daniel Fagerstrom wrote: is resolved in the same way as an ordinary external block URI. To make this possible the role of being a super block must be identifiable among the connections in the wiring info. Maybe by reserving the name "super" for this case. WDYT? /Daniel A few

Re: [RT] The block protocol

2005-04-05 Thread Daniel Fagerstrom
Vadim Gritsenko wrote: Daniel Fagerstrom wrote: --- o0o --- Just some sidenotes... The main involved components are the BlocksManager that in turn has access to one BlockManager for each block. (From [1] BlockManager is the ServiceManager of the block) Yes it is. We

Re: [RT] The block protocol

2005-04-05 Thread Bertrand Delacretaz
Le 5 avr. 05, à 09:10, Reinhard Poetz a écrit : ...I will revise http://wiki.apache.org/cocoon/Blocks (this weekend or next week) Thanks - wiki pages also make good "discussion checkpoints", and might allow more people to give feedback on the design. -Bertrand -- Bertrand Delacretaz independ

Re: [RT] The block protocol

2005-04-05 Thread Reinhard Poetz
Ralph Goers wrote: Daniel Fagerstrom wrote: is resolved in the same way as an ordinary external block URI. To make this possible the role of being a super block must be identifiable among the connections in the wiring info. Maybe by reserving the name "super" for this case. WDYT? /Daniel A few

Re: [RT] The block protocol

2005-04-05 Thread Reinhard Poetz
Bertrand Delacretaz wrote: Le 5 avr. 05, à 04:42, Ralph Goers a écrit : ...When the email gets to be long or quotes previous nested emails in their entirety I tend to just move on and ignore the post... FWIW, it is exactly my case: not enough time to follow these lng emails. The mailing-lis

Re: [RT] The block protocol

2005-04-04 Thread Bertrand Delacretaz
Le 5 avr. 05, à 04:42, Ralph Goers a écrit : ...When the email gets to be long or quotes previous nested emails in their entirety I tend to just move on and ignore the post... FWIW, it is exactly my case: not enough time to follow these lng emails. The mailing-list discussion mode makes it v

Re: [RT] The block protocol

2005-04-04 Thread Ralph Goers
Daniel Fagerstrom wrote: is resolved in the same way as an ordinary external block URI. To make this possible the role of being a super block must be identifiable among the connections in the wiring info. Maybe by reserving the name "super" for this case. WDYT? /Daniel A few thoughts here (tha

Re: [RT] The block protocol

2005-04-04 Thread Vadim Gritsenko
Daniel Fagerstrom wrote: --- o0o --- Just some sidenotes... The main involved components are the BlocksManager that in turn has access to one BlockManager for each block. (From [1] BlockManager is the ServiceManager of the block) Block local access --

[RT] The block protocol (was: RFC-2396)

2005-04-04 Thread Daniel Fagerstrom
Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 4 Apr 2005, at 16:26, Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 31 Mar 2005, at 01:26, Stefano Mazzocchi wrote: block:super://blah.xml A very simple remark, I don't want to criticise... I'm already slightly "upset" about the "cocoon://" pro