You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2005/04/04 23:28:47 UTC
[RT] The block protocol (was: RFC-2396)
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://" protocol, as it
>>>> does not follow the URI RFC properly, I'd like to address the
>>>> problem as early as possible...
>>>>
>>>> http://www.ietf.org/rfc/rfc2396.txt
>>>>
>>>> I wrote a small "rant" while on the plane, just to explain my
>>>> reasoning, with a couple of code examples, as it's (I don't think)
>>>> mailing-list material, I've stored it on my WIKI...
>>>>
>>>> http://www.betaversion.org/~pier/wiki/display/pier/Cocoon+and+URIs
<snip/>
>> Exactly... That's why I'm thinking that the URI should be this:
>>
>> block:portal:/foo
>>
>> block is an opaque URI, whose scheme specific part _is_ a valid URI by
>> itself.
>>
>> portal:/foo is a valid URI, but if (for example) you think about other
>> cases, this URI could be
>>
>> block:xmlrpc://www.myrpcserver.dom/entry/point
>>
>> block: opaque URI
>> xmlrpc: valid URI whose scheme specific part (whether it's opaque,
>> absolute, relative, blah) is only known by the "xmlrpc" handler...
>>
>> block:portal:/foo
>>
>> What's "/foo"? Only the portal block knows it...
<snip/>
I have thougth a litle bit more about the block URI and the architecture
around it so I do a new trial.
--- o0o ---
The main involved components are the BlocksManager that in turn has
access to one BlockManager for each block.
Block local access
------------------
Each BlockManager has its own SourceResolver and especially it can have
its own implementation of the block protocol which is registred with the
scheme "block:".
An absolute URI relative to the root sitemap of the block looks like:
block:/foo/bar
and is a hierarchical URI. It is invoked by first trying "foo/bar" in
the current block's root sitemap and if that fails
"block:super:/foo/bar" is invoked. More about "block:super:" later. To
make this work I would assume that error handling must work a little bit
different in blocks so that a sitemap can fail without emmiting any
error messages immediatly.
In the case when a block A has invoked an URI in its super block B, to
achieve polymorphism, all block protocoll resolution in B must be done
by first asking A's block resolver before trying its own.
A relative URI in a sub sitemap "/foo" from the block's root sitemap,
block:./bar
(an opaque URI) is resolved to
block:/foo/bar
using the same method as Pier used for the cocoon protocol in his Wiki.
Inter block access
------------------
An URI to another block "skin" e.g. looks like:
block:skin:/foo/bar
the BlockManager 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
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.
<comment>
Is the URI unique enough? What if I want several variants of the skin
that has different deployment parameters and implementations of theire
connections.
</comment>
Interesting enough, IIUC, blocks are only accessible through the block
protocol from other blocks, as the short name, "skin" e.g., only exists
in the block wiring info. Are we going to consider the main sitemap part
of a block as well to be able to access blocks from it?
Next the block manager asks the blocks manager for the URI, this could
be done through a "blocks:" protocol that is connected to the blocks
manager. The uri "block:skin:/foo/bar" could be resolved to e.g.:
blocks:{http://mycompany.com/skins/corporate/34.3.345}:/foo/bar
Besides that it looks awfull I would doubt that it even is synatactic
correct as an opaque URI. I only wrote it down to provoke you to find
something better ;)
Next the blocks manager looks up the block manager identified by
"http://mycompany.com/skins/corporate/34.3.345" and send the URI:
block:/foo/bar
to it, which will be resolved by the skin blocks internal implementation
of the block protocol.
block:super:/foo/bar
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
Re: Multiple block instances
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>>>> Another case is if we follow the method of handling the profile
>>>> info for a portal block that Reinhard proposed. If we want to use
>>>> two portals under the same Cocoon the portal block will be deployed
>>>> in two instances with different implementations of the profile
>>>> contract. Also here is the question is how we differ between the
>>>> two instances.
>>>
>>>
>>>
>>> Let's assume that you want to deploy two custom blocks that are
>>> based on the portal block. Doing so leds to two different blocks
>>> (--> different block IDs) which both extend the same block. Both
>>> blocks can use the same profile block to be customized or each gets
>>> its own - depends on your requirements.
>>
>>
>>
>> If we compare the situation with concepts from Java, my view was:
>>
>> Java: You download a class with unique combination of name and
>> namespace.
>> Blocks: You download a block with a unique URI.
>>
>> Java: You call the constuctor of the class possibly with parameters
>> and get an object with an unique object id.
>> Blocks: You deploy the block and get a block instance with a unique
>> (in your Cocoon) block instance id. During deployment you give it
>> parameter values and connect it to other block instances.
>>
>> --- o0o ---
>>
>> I guess that in your view there is no istantiation, you subclass and
>> have everything "static" instead.
>>
>> Both views will solve the same problem but in different ways. With
>> your view we might want to have tool support for automatic
>> subclassing ;)
>
>
> It should be as simple as writing a new block.xml and make a .cob out
> of it. btw, I heard of some project called Lepido .... ;-)
>
> After reading your mail I thought a bit about block instances but IMO
> they make things more difficult: where to put the 'constructor
> parameters', URI resolving and maybe more stuff.
In my view there is nearly no extra difficulty. The BlockManager
represents an instance and the deployment parameters and connections are
the constructor parameters. The only differnce is that a identifier is
generated at deploy time so that several BlockManagers can represent the
same Block but with different parameter and connection values.
> Maybe we really need them but this will be clearified after we set up
> some usecases using a working prototype.
Sure, it will only affect the identifier in the wiring and some
fuctionality in the deployer. For the communication between the
BlockManager and the BlocksManager it shouldn't matter. So its no big
deal to change it when we see that we need it ;)
/Daniel
Re: Multiple block instances
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
>>> Another case is if we follow the method of handling the profile info
>>> for a portal block that Reinhard proposed. If we want to use two
>>> portals under the same Cocoon the portal block will be deployed in
>>> two instances with different implementations of the profile contract.
>>> Also here is the question is how we differ between the two instances.
>>
>>
>> Let's assume that you want to deploy two custom blocks that are based
>> on the portal block. Doing so leds to two different blocks (-->
>> different block IDs) which both extend the same block. Both blocks can
>> use the same profile block to be customized or each gets its own -
>> depends on your requirements.
>
>
> If we compare the situation with concepts from Java, my view was:
>
> Java: You download a class with unique combination of name and namespace.
> Blocks: You download a block with a unique URI.
>
> Java: You call the constuctor of the class possibly with parameters and
> get an object with an unique object id.
> Blocks: You deploy the block and get a block instance with a unique (in
> your Cocoon) block instance id. During deployment you give it parameter
> values and connect it to other block instances.
>
> --- o0o ---
>
> I guess that in your view there is no istantiation, you subclass and
> have everything "static" instead.
>
> Both views will solve the same problem but in different ways. With your
> view we might want to have tool support for automatic subclassing ;)
It should be as simple as writing a new block.xml and make a .cob out of it.
btw, I heard of some project called Lepido .... ;-)
After reading your mail I thought a bit about block instances but IMO they make
things more difficult: where to put the 'constructor parameters', URI resolving
and maybe more stuff. Maybe we really need them but this will be clearified
after we set up some usecases using a working prototype.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Multiple block instances
Posted by Ralph Goers <Ra...@dslextreme.com>.
Daniel Fagerstrom wrote:
> If we compare the situation with concepts from Java, my view was:
>
> Java: You download a class with unique combination of name and namespace.
> Blocks: You download a block with a unique URI.
>
> Java: You call the constuctor of the class possibly with parameters
> and get an object with an unique object id.
> Blocks: You deploy the block and get a block instance with a unique
> (in your Cocoon) block instance id. During deployment you give it
> parameter values and connect it to other block instances.
This depends on whether the Java class is a singleton, in which case the
constructor is called only when the class is instantiated the first
time. The same could be true for blocks as well, if that is desirable.
It probably would be more manaageable if the first release required that
blocks be singletons and then expand that later if needed. Isn't that
basically the way servlets work?
>
>
> --- o0o ---
>
> I guess that in your view there is no istantiation, you subclass and
> have everything "static" instead.
Being a singleton doesn't mean that you can't have some initialization.
>
> Both views will solve the same problem but in different ways. With
> your view we might want to have tool support for automatic subclassing ;)
>
> /Daniel
>
Re: Multiple block instances
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> Consider the following case: One of my applications use a repository
>> block, and this repository block has a db connection with name and
>> password as deplyment parameters. If another application need to use
>> the same repository block, but connected to another db it will have
>> other deployment parameters. In this case we will have two deployed
>> instances of the same block with different deployment parameters. How
>> do we differ between them.
>
>
> If you need different behaviour of one block you will have to extend
> it (so it gets another unique ID) and only change the properties in
> block.xml.
ok.
> (Although I think that this isn't a good example because it's not a
> consuming block's concern to set the database connection IMO).
Didn't suggest that. What I described above was supposed to happen at
deploy time. The two applications only know that they talk with a block
that fullfills the repository contract.
>> Another case is if we follow the method of handling the profile info
>> for a portal block that Reinhard proposed. If we want to use two
>> portals under the same Cocoon the portal block will be deployed in
>> two instances with different implementations of the profile contract.
>> Also here is the question is how we differ between the two instances.
>
> Let's assume that you want to deploy two custom blocks that are based
> on the portal block. Doing so leds to two different blocks (-->
> different block IDs) which both extend the same block. Both blocks can
> use the same profile block to be customized or each gets its own -
> depends on your requirements.
If we compare the situation with concepts from Java, my view was:
Java: You download a class with unique combination of name and namespace.
Blocks: You download a block with a unique URI.
Java: You call the constuctor of the class possibly with parameters and
get an object with an unique object id.
Blocks: You deploy the block and get a block instance with a unique (in
your Cocoon) block instance id. During deployment you give it parameter
values and connect it to other block instances.
--- o0o ---
I guess that in your view there is no istantiation, you subclass and
have everything "static" instead.
Both views will solve the same problem but in different ways. With your
view we might want to have tool support for automatic subclassing ;)
/Daniel
Multiple block instances
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Consider the following case: One of my applications use a repository
> block, and this repository block has a db connection with name and
> password as deplyment parameters. If another application need to use the
> same repository block, but connected to another db it will have other
> deployment parameters. In this case we will have two deployed instances
> of the same block with different deployment parameters. How do we differ
> between them.
If you need different behaviour of one block you will have to extend it (so it
gets another unique ID) and only change the properties in block.xml.
(Although I think that this isn't a good example because it's not a consuming
block's concern to set the database connection IMO).
>
> Another case is if we follow the method of handling the profile info for
> a portal block that Reinhard proposed. If we want to use two portals
> under the same Cocoon the portal block will be deployed in two instances
> with different implementations of the profile contract. Also here is the
> question is how we differ between the two instances.
Let's assume that you want to deploy two custom blocks that are based on the
portal block. Doing so leds to two different blocks (--> different block IDs)
which both extend the same block. Both blocks can use the same profile block to
be customized or each gets its own - depends on your requirements.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT] The block protocol
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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 of my applications use a repository
>> block, and this repository block has a db connection with name and
>> password as deplyment parameters. If another application need to use
>> the same repository block, but connected to another db it will have
>> other deployment parameters. In this case we will have two deployed
>> instances of the same block with different deployment parameters. How
>> do we differ between them.
>
>
> Context.
>
> Here is your problem:
>
> [ Block A -(requires)-> Block C ] -(named)-> 'database'
> [ Block B -(requires)-> Block C ] -(named)-> 'database'
>
> this is the 'structure' of the dependency, not your actual instance.
>
> When you install Block A, the block deployer (thanks Reinhard for
> correcting me) will look for Block C (let's not dicuss the 'how' of
> this now).
>
> The block will be fetched, unpacked, configured and wired. At this
> point, Block C will become known (to A!) as "database" and from the
> block A, you can call "block:database:/" and that *instance* of block
> C will respond.
>
> Note that since java classloading is already namespaced, you *DO NOT*
> need to provide a block hint for the classloading: if Block C provides
> a class called
>
> org.myhost.myapp.myblock.Database
>
> you flowscript in block A can call
>
> cocoon.getComponent("org.myhost.myapp.myblock.Database")
>
> and obtain that *instance*, configured as you wanted at installation
> time (here, you will be asked for username/password/jdbc-url etc.).
>
> Now, later on, you install Block B, which requires an instance of
> Block C. You already have one installed, so the block deployer will
> ask you if you want to reuse that instance or another one.
>
> at this point, if you want to use another instance (keep the code, but
> change the behavior thru different configurations!), the block manager
> (and its internal classloader and sitemap mounter) will make sure that
> if you call block:database:/ from block B, you end up in *another*
> instance, with different configurations and different parameters.
>
Yes, sounds good.
/Daniel
Re: [RT] The block protocol
Posted by Stefano Mazzocchi <st...@apache.org>.
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 repository
> block, and this repository block has a db connection with name and
> password as deplyment parameters. If another application need to use the
> same repository block, but connected to another db it will have other
> deployment parameters. In this case we will have two deployed instances
> of the same block with different deployment parameters. How do we differ
> between them.
Context.
Here is your problem:
[ Block A -(requires)-> Block C ] -(named)-> 'database'
[ Block B -(requires)-> Block C ] -(named)-> 'database'
this is the 'structure' of the dependency, not your actual instance.
When you install Block A, the block deployer (thanks Reinhard for
correcting me) will look for Block C (let's not dicuss the 'how' of this
now).
The block will be fetched, unpacked, configured and wired. At this
point, Block C will become known (to A!) as "database" and from the
block A, you can call "block:database:/" and that *instance* of block C
will respond.
Note that since java classloading is already namespaced, you *DO NOT*
need to provide a block hint for the classloading: if Block C provides a
class called
org.myhost.myapp.myblock.Database
you flowscript in block A can call
cocoon.getComponent("org.myhost.myapp.myblock.Database")
and obtain that *instance*, configured as you wanted at installation
time (here, you will be asked for username/password/jdbc-url etc.).
Now, later on, you install Block B, which requires an instance of Block
C. You already have one installed, so the block deployer will ask you if
you want to reuse that instance or another one.
at this point, if you want to use another instance (keep the code, but
change the behavior thru different configurations!), the block manager
(and its internal classloader and sitemap mounter) will make sure that
if you call block:database:/ from block B, you end up in *another*
instance, with different configurations and different parameters.
--
Stefano.
Re: [RT] The block protocol
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
<snip/>
>>>> 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.
>>>>
>>>> <comment>
>>>> 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. I agree that a unique identifier created at deploy time
>> by the BlocksManager is needed.
>
> 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 repository
block, and this repository block has a db connection with name and
password as deplyment parameters. If another application need to use the
same repository block, but connected to another db it will have other
deployment parameters. In this case we will have two deployed instances
of the same block with different deployment parameters. How do we differ
between them.
Another case is if we follow the method of handling the profile info for
a portal block that Reinhard proposed. If we want to use two portals
under the same Cocoon the portal block will be deployed in two instances
with different implementations of the profile contract. Also here is the
question is how we differ between the two instances.
>>>> </comment>
>>>>
>>>> Interesting enough, IIUC, blocks are only accessible through the
>>>> block protocol from other blocks,
>>>
>>> No; IMHO they are all available through BlocksManager.
>>
> Well, no. The BlockManager has block 'scopes' and should allow a block
> to resolve only the blocks that it explicitly depended upon and for
> which it has a name for. The rest is just like it wasn't there... and
> this is required to avoid polymorphism without unwanted collisions.
>
>> 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.
>
> Exactly.
>
>> 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.
>
> YAGNI: if you need a block, declare that you need it and associate a
> name with it. Otherwise, you don't need it, you don't have access to it.
>
With declaring it, do you mean that we have a block deployment
descriptor that is connected to the main sitemap?
/Daniel
Re: [RT] The block protocol
Posted by Stefano Mazzocchi <st...@apache.org>.
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" 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. 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.
This is correct.
> I think this design is necessary for achieving scalability. If the short
> name was assumed to be unique, we would get name clashes between
> external blocks developers.
Absolutely: URI gets prefixed and are used only in the local wiring
context, they lose meaning if detached from the block that uses them.
Also because the "using" block is responsible for this mapping:
[ http://host/myBlock/3.4.34 -(requires)-> http://blah/skin/2.3 ]
--(calls it)--> "skin"
so, block:skin: used inside http://host/myBlock/3.4.34 will point to
whatever http://blah/skin/2.3 implementation you decided to wire it to,
but block:skin: used somewhere might route somewhere else.
So, "skin" has no absolute meaning, just local and it's still a solid
contract because it's defined by the requiring block, which is the only
one using and in-control-of that name.
>>> 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
>>
>>
>>
>> Beside mapping, BlocksManager can fetch an instance of the referenced
>> Block, i.e. its BlockManager. Not sure if URI by itself is needed at all.
>
>
> 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. But it is
> more of an implementation detail. Isolation can be achieved in other ways.
You don't need global block identifiers other than their URIs (which are
meant to be 'globally' unique, not just locally).
>>> 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.
>>>
>>> <comment>
>>> 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. I agree that a unique identifier created at deploy time by
> the BlocksManager is needed.
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.
>>> </comment>
>>>
>>> Interesting enough, IIUC, blocks are only accessible through the
>>> block protocol from other blocks,
>>
>>
>> No; IMHO they are all available through BlocksManager.
Well, no. The BlockManager has block 'scopes' and should allow a block
to resolve only the blocks that it explicitly depended upon and for
which it has a name for. The rest is just like it wasn't there... and
this is required to avoid polymorphism without unwanted collisions.
> 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.
Exactly.
> 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.
YAGNI: if you need a block, declare that you need it and associate a
name with it. Otherwise, you don't need it, you don't have access to it.
--
Stefano.
Re: [RT] The block protocol
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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.
>>>
>>> <comment>
>>> 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 :-)
>>> </comment>
>>>
>>> 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
Re: [RT] The block protocol
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
>
>> --- o0o ---
>
>
> </lurk>
> 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 need to discuss the details about component managment in
blocks also. My mail was only about the block protocol aspect of the
architecture.
>> Block local access
>> ------------------
>>
>> Each BlockManager has its own SourceResolver and especially it can
>> have its own implementation of the block protocol which is registred
>> with the scheme "block:".
>>
>> An absolute URI relative to the root sitemap of the block looks like:
>>
>> block:/foo/bar
>>
>> and is a hierarchical URI. It is invoked by first trying "foo/bar" in
>> the current block's root sitemap and if that fails
>> "block:super:/foo/bar" is invoked.
>
>
> You don't need that. As mentioned in [1], local BlockManager has
> access to the parent BlockManager, so local BlockSource instance will
> lookup parent BlockSource and delegate to it. (Or may be this is just
> another way of saying the same? Hm.)
I think we mean the same.
>> More about "block:super:" later. To make this work I would assume
>> that error handling must work a little bit different in blocks so
>> that a sitemap can fail without emmiting any error messages immediatly.
>
> That's the only behaviour available in 2.1.6 and below.
Ok.
>> In the case when a block A has invoked an URI in its super block B,
>> to achieve polymorphism, all block protocoll resolution in B must be
>> done by first asking A's block resolver before trying its own.
>
>
> So it means local SourceResolver (or it's settings) should be
> preserved for the duration of polymorphic source processing.
Yes.
>> A relative URI in a sub sitemap "/foo" from the block's root sitemap,
>>
>> block:./bar
>>
>> (an opaque URI) is resolved to
>>
>> block:/foo/bar
>>
>> using the same method as Pier used for the cocoon protocol in his Wiki.
>>
>> 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. 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.
I think this design is necessary for achieving scalability. If the short
name was assumed to be unique, we would get name clashes between
external blocks developers.
>> 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
>
>
> Beside mapping, BlocksManager can fetch an instance of the referenced
> Block, i.e. its BlockManager. Not sure if URI by itself is needed at all.
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. But it is
more of an implementation detail. Isolation can be achieved in other ways.
>> 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.
>>
>> <comment>
>> 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. I agree that a unique identifier created at deploy time by
the BlocksManager is needed.
>> </comment>
>>
>> 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.
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.
>> as the short name, "skin" e.g., only exists in the block wiring info.
>> Are we going to consider the main sitemap part of a block as well to
>> be able to access blocks from it?
>
> (I did not get this question).
Is it clearer from my explanations above.
>> Next the block manager asks the blocks manager for the URI,
>
> Nope. No need - it can simply ask for BlockManager.
>
>> this could be done through a "blocks:" protocol that is connected to
>> the blocks manager. The uri "block:skin:/foo/bar" could be resolved
>> to e.g.:
>>
>> blocks:{http://mycompany.com/skins/corporate/34.3.345}:/foo/bar
>>
>> Besides that it looks awfull I would doubt that it even is synatactic
>> correct as an opaque URI. I only wrote it down to provoke you to find
>> something better ;)
>
> IMHO, it (BlockManager) does not need URI of another block, at all. So
> no need for writing awful URIs :-P
See above.
>> Next the blocks manager looks up the block manager identified by
>> "http://mycompany.com/skins/corporate/34.3.345" and send the URI:
>>
>> block:/foo/bar
>>
>> to it, which will be resolved by the skin blocks internal
>> implementation of the block protocol.
>
> Yep.
>
>> block:super:/foo/bar
>>
>> 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
>
> Vadim
> <lurk>
>
> [1] http://wiki.apache.org/cocoon/22BlockImplementation
/Daniel
Re: [RT] The block protocol
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
> --- o0o ---
</lurk>
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
> ------------------
>
> Each BlockManager has its own SourceResolver and especially it can have
> its own implementation of the block protocol which is registred with the
> scheme "block:".
>
> An absolute URI relative to the root sitemap of the block looks like:
>
> block:/foo/bar
>
> and is a hierarchical URI. It is invoked by first trying "foo/bar" in
> the current block's root sitemap and if that fails
> "block:super:/foo/bar" is invoked.
You don't need that. As mentioned in [1], local BlockManager has access to the
parent BlockManager, so local BlockSource instance will lookup parent
BlockSource and delegate to it. (Or may be this is just another way of saying
the same? Hm.)
> More about "block:super:" later. To
> make this work I would assume that error handling must work a little bit
> different in blocks so that a sitemap can fail without emmiting any
> error messages immediatly.
That's the only behaviour available in 2.1.6 and below.
> In the case when a block A has invoked an URI in its super block B, to
> achieve polymorphism, all block protocoll resolution in B must be done
> by first asking A's block resolver before trying its own.
So it means local SourceResolver (or it's settings) should be preserved for the
duration of polymorphic source processing.
> A relative URI in a sub sitemap "/foo" from the block's root sitemap,
>
> block:./bar
>
> (an opaque URI) is resolved to
>
> block:/foo/bar
>
> using the same method as Pier used for the cocoon protocol in his Wiki.
>
> Inter block access
> ------------------
>
> An URI to another block "skin" e.g. looks like:
>
> block:skin:/foo/bar
>
> the BlockManager
You probably meant here "BlocksManager"
> 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
Beside mapping, BlocksManager can fetch an instance of the referenced Block,
i.e. its BlockManager. Not sure if URI by itself is needed at all.
> 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.
>
> <comment>
> 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).
> </comment>
>
> Interesting enough, IIUC, blocks are only accessible through the block
> protocol from other blocks,
No; IMHO they are all available through BlocksManager.
> as the short name, "skin" e.g., only exists
> in the block wiring info. Are we going to consider the main sitemap part
> of a block as well to be able to access blocks from it?
(I did not get this question).
> Next the block manager asks the blocks manager for the URI,
Nope. No need - it can simply ask for BlockManager.
> this could
> be done through a "blocks:" protocol that is connected to the blocks
> manager. The uri "block:skin:/foo/bar" could be resolved to e.g.:
>
> blocks:{http://mycompany.com/skins/corporate/34.3.345}:/foo/bar
>
> Besides that it looks awfull I would doubt that it even is synatactic
> correct as an opaque URI. I only wrote it down to provoke you to find
> something better ;)
IMHO, it (BlockManager) does not need URI of another block, at all. So no need
for writing awful URIs :-P
> Next the blocks manager looks up the block manager identified by
> "http://mycompany.com/skins/corporate/34.3.345" and send the URI:
>
> block:/foo/bar
>
> to it, which will be resolved by the skin blocks internal implementation
> of the block protocol.
Yep.
> block:super:/foo/bar
>
> 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
Vadim
<lurk>
[1] http://wiki.apache.org/cocoon/22BlockImplementation
Re: [RT] The block protocol
Posted by Stefano Mazzocchi <st...@apache.org>.
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",
>> "MyProfile2", ..., "MyProfileN".
>>
>>
>>>> <profiles>
>>>> <copletbasedata-load
>>>> uri="blocks:profile:/load-global-profile?profile=copletbasedata"/>
>>>> <copletdata-global-load
>>>> uri="blocks:profile:/load-global-profile?profile=copletdata"/>
>>>> ..
>>>> </profiles>
>>>>
>>>> The problem with this example is that is not how the portal works,
>>>> nor would I ever want the portal to require that a block with a
>>>> specific name be present as this prohibits two portal
>>>> implementations from being present in the same webapp.
>>>
>>>
>>>
>>>
>>> That's not true. You can deploy as many portal applications as real
>>> blocks as you want.
>>
>>
>>
>> Yes
>>
>>
>>> And, if you don't like dependencies (references, extensions) just
>>> don't use them.
>>
>>
>>
>> And No. If portal block requires implementation of profile block,
>> during its deployment time you will pick up an implementation you like
>> for each instance of portal block.
>
>
> ... stand corrected
>
> and you have always the chance that you can do it the same way as it is
> done now: simply copy everything that you need into your own application.
>
> If people really want this, the portal block could have a "base" version
> that only contains the components (e.g. the PortalGenerator) and a
> "default" version that extends the base version and requires a "profile"
> block.
>
> Then people who like blocks and that functionality is spreat over
> several blocks extend the "default" version and people who don't want to
> change the way how they work with Cocoon, use the "base" block that only
> contains components.
There are two concerns here, not totally unrelated, but enough so:
1) what features should the block system have
2) what is the best way to use those features in order to achieve what
I need
We have a pretty good understanding of 1) (and meets *all* the
requirements that I came across so far!) but have no idea on best
practices for 2)
I would strongly suggest we avoid discussing #2 before we even implement
#1 to test it out.
Obviously, the two cannot be completely isolated, because #1 influences
#2 and problems in #2 should influence back #1, so the cycle will be
iterative, but for now, let's focus on what we understand of #1 and move
on until we have a better understanding of the problems on #2.
--
Stefano.
Re: [RT] The block protocol
Posted by Reinhard Poetz <re...@apache.org>.
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", ..., "MyProfileN".
>
>
>>> <profiles>
>>> <copletbasedata-load
>>> uri="blocks:profile:/load-global-profile?profile=copletbasedata"/>
>>> <copletdata-global-load
>>> uri="blocks:profile:/load-global-profile?profile=copletdata"/>
>>> ..
>>> </profiles>
>>>
>>> The problem with this example is that is not how the portal works,
>>> nor would I ever want the portal to require that a block with a
>>> specific name be present as this prohibits two portal implementations
>>> from being present in the same webapp.
>>
>>
>>
>> That's not true. You can deploy as many portal applications as real
>> blocks as you want.
>
>
> Yes
>
>
>> And, if you don't like dependencies (references, extensions) just
>> don't use them.
>
>
> And No. If portal block requires implementation of profile block, during
> its deployment time you will pick up an implementation you like for each
> instance of portal block.
... stand corrected
and you have always the chance that you can do it the same way as it is done
now: simply copy everything that you need into your own application.
If people really want this, the portal block could have a "base" version that
only contains the components (e.g. the PortalGenerator) and a "default" version
that extends the base version and requires a "profile" block.
Then people who like blocks and that functionality is spreat over several blocks
extend the "default" version and people who don't want to change the way how
they work with Cocoon, use the "base" block that only contains components.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT] The block protocol
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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".
>> <profiles>
>> <copletbasedata-load
>> uri="blocks:profile:/load-global-profile?profile=copletbasedata"/>
>> <copletdata-global-load
>> uri="blocks:profile:/load-global-profile?profile=copletdata"/>
>> ..
>> </profiles>
>>
>> The problem with this example is that is not how the portal works, nor
>> would I ever want the portal to require that a block with a specific
>> name be present as this prohibits two portal implementations from
>> being present in the same webapp.
>
>
> That's not true. You can deploy as many portal applications as real
> blocks as you want.
Yes
> And, if you don't like dependencies (references,
> extensions) just don't use them.
And No. If portal block requires implementation of profile block, during its
deployment time you will pick up an implementation you like for each instance of
portal block.
Vadim
Re: [RT] The block protocol
Posted by Reinhard Poetz <re...@apache.org>.
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 thoughts here (that aren't necessarily directed at you):
> 1. I may have missed some points in this discussion. 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. So, as a rule I would recommend
> keeping posts as short and sweet as possible. If you'll notice, there
> have only been a few participants in these discussions. Maybe its just
> me, but I wonder if others aren't jumping in with their thoughts for the
> same reason.
I have the same feeling - but discussing based on examples is difficult,
especially if the examples are very long ...
> 2. I've noticed a few discussions that are mainly between you and
> Reinhard with other folks posting occaisionally. Although you two may
> come to agreement on some ideas, given item 1 I wonder if it actually is
> the concensus of the community.
No, I don't think that everybody who hasn't contributed to the discussion is in
agreement with Daniel, Stefano and me. It will be much easier when the first
prototype is available.
> Maybe I'm wrong though, and maybe most
> of the commtters just aren't interested.
I don't understand this. If somebody isn't interested, he shouldn't have a
problem with the discussion. It's a bigger problem that if people *were*
interested and don't like the long mails that they would have to say important
things but they don't want to invest that much time in following the discussions.
As said in my reply to Betrand's mail, I will try to revise the original design
proposal by Stefano (as far as I can see there are only some minor things that
have changed or were extended + I will also add relevant links to mails)
> 3. I've had a real problem with the previous "blocks" discussion and how
> it used the Portal as an example. I'm not sure that it is actually
> understood what needs to happen with the portal to make it into a "real
> block". The issue with the portal is that the framework (what would be
> the portal block) requires quite a few definitions, both in components
> and in the sitemap. These definitions must be provided by the portal
> implementation. If the portal implementation must provide the
> definitions then there really is no need for a block protocol as there
> is nothing in the portal block to invoke, other than the sitemap
> components provided by it. In message
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111245388030013&w=2,
> Reinhard said "The block "portal" only contains pipelines calls which
> the block "profile" provides in its sitemap
>
> Portal block
> ------------
> - requires "MyProfile" that implements "profile"
>
> <profiles>
> <copletbasedata-load
> uri="blocks:profile:/load-global-profile?profile=copletbasedata"/>
> <copletdata-global-load
> uri="blocks:profile:/load-global-profile?profile=copletdata"/>
> ..
> </profiles>
>
> The problem with this example is that is not how the portal works, nor
> would I ever want the portal to require that a block with a specific
> name be present as this prohibits two portal implementations from being
> present in the same webapp.
That's not true. You can deploy as many portal applications as real blocks as
you want. And, if you don't like dependencies (references, extensions) just
don't use them. The example above was for the sake of showing that things *can*
be separated if people like it. E.g. you could deploy 5 portal applications all
using the same skin block.
In fact, these definitions must be in the
> application, not the portal block.
as said above, it's your choice. If you want to do things in the future as you
have always done, put your application into a single block and only minor things
will change for you (you have to provide a block.xml file, that's it).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT] The block protocol
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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 thoughts here (that aren't necessarily directed at you):
> 1. I may have missed some points in this discussion. 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. So, as a rule I would
> recommend keeping posts as short and sweet as possible.
While I agree in general, It is quite hard to achieve. At some point we
need to get from discussing about the general requirements and the broad
vision about things, and get into designing the gory details. And at
that point we need to use examples (which takes place) to assure that
our proposed solutions actually work and that we talking about the same
things. It is also necessary to discuss some edge cases that most users
hopefully don't need to understand, but which would bite them if we
didin't take care about them in the design.
> If you'll notice, there have only been a few participants in these
> discussions. Maybe its just me, but I wonder if others aren't jumping
> in with their thoughts for the same reason.
I have certainly noticed that there are few participant in the
discussion. I think an important reason is that the discussed subject
(blocks) is rather difficult and takes quite some while to learn enough
about to be able to participate in detailed design discussions.
For my own part I found blocks attractive and important from the very
beginning, when Stefano presented them maybe three years ago. But it
took me long time before I started to participate in the discussions as
the focus on the blocks work in the beginning was about things that I
didn't know much about. People believed that it was necessary to switch
component manager before we could start to actually implement blocks.
And I didn't know much about componment managers back then.
Anyway, if you (or others) think that we are dicussing something that
you would like to participate in but is lost in all the details, just
ask us about some background or for a summary of the issues. As long as
you don't comment it is hard to know if anyone reads. And the allready
long mails would be endless if we by default started with a summary of
the whole thread.
> 2. I've noticed a few discussions that are mainly between you and
> Reinhard with other folks posting occaisionally. Although you two may
> come to agreement on some ideas, given item 1 I wonder if it actually
> is the concensus of the community.
I'm certain that people will start to have opinions when we start to
have an implementation. Until then lazy concensus is enough.
<snip>stuff that Reinhard commented</snip>
/Daniel
Re: [RT] The block protocol
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
independent consultant, Lausanne, Switzerland
http://www.codeconsult.ch
Re: [RT] The block protocol
Posted by Reinhard Poetz <re...@apache.org>.
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 loooong
> emails. The mailing-list discussion mode makes it very hard to work on
> such (important I'm afraid) design issues collectively.
>
> Not that I have a solution, just wanted to reinforce what Ralph is
> saying. Or maybe one suggestion: if the people involved in these
> discussions could post [SUMMARY] messages as a kind of checkpoint along
> the way from time to time, it might help more people get involved based
> on what's been agreed in the discussion so far.
as said the discussions were very long and maybe Daniel, Stefano and I were the
only ones who were able to follow it.
I will revise http://wiki.apache.org/cocoon/Blocks (this weekend or next week)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT] The block protocol
Posted by Bertrand Delacretaz <bd...@apache.org>.
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 loooong
emails. The mailing-list discussion mode makes it very hard to work on
such (important I'm afraid) design issues collectively.
Not that I have a solution, just wanted to reinforce what Ralph is
saying. Or maybe one suggestion: if the people involved in these
discussions could post [SUMMARY] messages as a kind of checkpoint along
the way from time to time, it might help more people get involved based
on what's been agreed in the discussion so far.
-Bertrand
Re: [RT] The block protocol
Posted by Ralph Goers <Ra...@dslextreme.com>.
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 (that aren't necessarily directed at you):
1. I may have missed some points in this discussion. 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. So, as a rule I would recommend
keeping posts as short and sweet as possible. If you'll notice, there
have only been a few participants in these discussions. Maybe its just
me, but I wonder if others aren't jumping in with their thoughts for the
same reason.
2. I've noticed a few discussions that are mainly between you and
Reinhard with other folks posting occaisionally. Although you two may
come to agreement on some ideas, given item 1 I wonder if it actually is
the concensus of the community. Maybe I'm wrong though, and maybe most
of the commtters just aren't interested.
3. I've had a real problem with the previous "blocks" discussion and how
it used the Portal as an example. I'm not sure that it is actually
understood what needs to happen with the portal to make it into a "real
block". The issue with the portal is that the framework (what would be
the portal block) requires quite a few definitions, both in components
and in the sitemap. These definitions must be provided by the portal
implementation. If the portal implementation must provide the
definitions then there really is no need for a block protocol as there
is nothing in the portal block to invoke, other than the sitemap
components provided by it. In message
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111245388030013&w=2,
Reinhard said "The block "portal" only contains pipelines calls which
the block "profile" provides in its sitemap
Portal block
------------
- requires "MyProfile" that implements "profile"
<profiles>
<copletbasedata-load
uri="blocks:profile:/load-global-profile?profile=copletbasedata"/>
<copletdata-global-load
uri="blocks:profile:/load-global-profile?profile=copletdata"/>
..
</profiles>
The problem with this example is that is not how the portal works, nor
would I ever want the portal to require that a block with a specific
name be present as this prohibits two portal implementations from being
present in the same webapp. In fact, these definitions must be in the
application, not the portal block.
Ralph