You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Pier Fumagalli <pi...@betaversion.org> on 2005/04/03 22:57:11 UTC
RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
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
Anyhow, feel free to discuss it here...
Pier
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Peter Hunsberger <pe...@gmail.com>.
On Apr 4, 2005 11:16 AM, Daniel Fagerstrom <da...@nada.kth.se> wrote:
> Peter Hunsberger wrote:
>
> >On Apr 4, 2005 10:26 AM, Daniel Fagerstrom <da...@nada.kth.se> wrote:
> >
> >
> >>Pier Fumagalli wrote:
> >>
> >>
> >>
> >>>On 31 Mar 2005, at 01:26, Stefano Mazzocchi wrote:
> >>>
> >>>
> >
> ><snip/>
> >
> >
> >
> >>As all URI discussions tend to provoke strong feelings for Stefano, it's
> >>best to say directly that this question is not important enough for me
> >>to fight about ;)
> >>
> >>But anyway, whether we go for an opaque custom protocol or base the
> >>block protocol on hierachial URIs we need to get into the specifics for
> >>the block URI scheme to be able to implement it.
> >>
> >>WDYT?
> >>
> >>
> >
> >He, he... The more I look at this the more I wonder if maybe it
> >really isn't crazy to allow blocks to specify a resolver intercept
> >scheme. Just lift the code directly out of mod-rewrite/mod-redirect
> >and let a block tell Cocoon what URI's have special concerns:
> >
> ><resolver>match spec</resolver>
> >
> >then you can go either way...
> >
> >
> I'm not following you, we already has source factories, so we can make
> our resolver as special as we want to. The question was rather if we
> should make them less special by using java.net.URI. Or do you have
> something else in mind?
Basically, the idea is to have a way for a block to say to treat a
given set of URI's in a special manner by performing a remapping on
them. That way the incoming request can be generic and transformed
into something block specific _before_ it hits the source factory.
Eg, being able to say that
http://site.com/foo/bar.css
ends up as:
block:/foo/bar.css
where as:
../bar.css
gets passed through to Cocoon untouched, or vice versa, depending on
the needs of the block and the block user. Perhaps this might be
better expressed as a "remap" directive than a "resolve" directive...
--
Peter Hunsberger
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Peter Hunsberger wrote:
>On Apr 4, 2005 10:26 AM, Daniel Fagerstrom <da...@nada.kth.se> wrote:
>
>
>>Pier Fumagalli wrote:
>>
>>
>>
>>>On 31 Mar 2005, at 01:26, Stefano Mazzocchi wrote:
>>>
>>>
>
><snip/>
>
>
>
>>As all URI discussions tend to provoke strong feelings for Stefano, it's
>>best to say directly that this question is not important enough for me
>>to fight about ;)
>>
>>But anyway, whether we go for an opaque custom protocol or base the
>>block protocol on hierachial URIs we need to get into the specifics for
>>the block URI scheme to be able to implement it.
>>
>>WDYT?
>>
>>
>
>He, he... The more I look at this the more I wonder if maybe it
>really isn't crazy to allow blocks to specify a resolver intercept
>scheme. Just lift the code directly out of mod-rewrite/mod-redirect
>and let a block tell Cocoon what URI's have special concerns:
>
><resolver>match spec</resolver>
>
>then you can go either way...
>
>
I'm not following you, we already has source factories, so we can make
our resolver as special as we want to. The question was rather if we
should make them less special by using java.net.URI. Or do you have
something else in mind?
/Daniel
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Peter Hunsberger <pe...@gmail.com>.
On Apr 4, 2005 10:26 AM, Daniel Fagerstrom <da...@nada.kth.se> wrote:
> Pier Fumagalli wrote:
>
> > On 31 Mar 2005, at 01:26, Stefano Mazzocchi wrote:
<snip/>
>
> As all URI discussions tend to provoke strong feelings for Stefano, it's
> best to say directly that this question is not important enough for me
> to fight about ;)
>
> But anyway, whether we go for an opaque custom protocol or base the
> block protocol on hierachial URIs we need to get into the specifics for
> the block URI scheme to be able to implement it.
>
> WDYT?
He, he... The more I look at this the more I wonder if maybe it
really isn't crazy to allow blocks to specify a resolver intercept
scheme. Just lift the code directly out of mod-rewrite/mod-redirect
and let a block tell Cocoon what URI's have special concerns:
<resolver>match spec</resolver>
then you can go either way...
--
Peter Hunsberger
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
[RT] The block protocol (was: RFC-2396)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
>>>
>>> Anyhow, feel free to discuss it here...
>>
>>
>> I read your rant and agree with it, it seem benefical to take
>> advantage of java.net.URI. I'm not completely happy with letting
>> relative sitemap paths be opaque and absolute be hierarchical, but I
>> don't see any better alternatives.
>
>
> The thing is that the scheme specific part of the opaque URI, is
> actually a relative URI which can be resolved against an absolute one...
>
> URI relative_uri =
> absolute_uri.resolve(opaque_uri.getSchemeSpecificPart());
>
> As simple as that...
>
>>
>> Concerning:
>>
>> block:super://blah.xml
>>
>> it is AFAICS a correct opaque URI. But we could make better use of
>> java.net.URI if we considered a hierarchial URI scheme for blocks
>> instead. From this perspective the scheme that Reinhard suggested
>> makes sense
>>
>> block://portal/foo
>>
>> for refering to the absoute path "/foo" within the portal block,
>>
>> block:/foo
>>
>> for refering to the absolute path "/foo" within the current block and
>>
>> block:./bar
>>
>> for refering to the relative path "bar" relative to the current
>> (sub)sitemap within the current block and
>>
>> block:super:/foo
>>
>> for refering to the absolute path "foo" whithin the super block of
>> the current and possibly
>>
>> block:super:./bar
>>
>> for refering to the relative path "bar" relative to the current
>> (sub)sitemap within the super block of the current.
>>
>> The last three URIs are opaque and could be resolved to absolute
>> hierarchical URIs with a similar algorithm as you proposed for
>> "cocoon:./" resolution.
>>
>> Maybe using "//portal" as an authority is stretching the
>> intepretation to far.
>
>
> 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...
Ok, that makes sense. The specific blocks handler resolve the scheme
specific part. If we follow this path the blocks descriptor
(http://wiki.apache.org/cocoon/BlocksCob) must be extended with a
declaration about what source resolver to use.
It would still be good to have a default resolver for all blocks that
doesn't have specific needs, so that we get some coherence for our
blocks. And there we could use hierarchical URIs like those you propsed
in your wiki for the cocoon: protocol.
Question is how i.e. the portal block refers to its own pipes. If you
take a look at http://wiki.apache.org/cocoon/BlocksCob a block doesn't
have a short name for it self that can be used as scheme, it only
declares such names for the blocks it requires, so portal: doesn't make
any sense within the portal block. So within the specific block we could
maybe use:
block:/foo, block:./bar, block:super:/foo, block:super:./bar
whith the same intepretation as I suggested above (for the default
resolver).
This could be done in the way that each block define its own resolver
and bind it to the scheme block:, then when a block, portal e.g. use an
URI to another block, the block manager (for portal) will get an URI like:
block:skin:/foo
it will then find the block manager for the skin block and ask it to resolve
block:/foo
Which will use the resolver from the skin block.
/Daniel
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> The only problem I have with "block:super://blah.xml" is that "//" in an
> URI indicates the start of the authority part, and this is defined as
> "user@host:port", and no matter how you see it, "block:...anything..."
> _is_ a URI, and thus should follow its spec...
>
> Pier
>
>>
>> --- o0o ---
>>
>> As all URI discussions tend to provoke strong feelings for Stefano,
>> it's best to say directly that this question is not important enough
>> for me to fight about ;)
Despite dry humor, I have no problems deprecating the use of // in the
cocoon: and block: URI scheme.
--
Stefano.
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Pier Fumagalli <pi...@betaversion.org>.
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
>>
>> Anyhow, feel free to discuss it here...
>
> I read your rant and agree with it, it seem benefical to take
> advantage of java.net.URI. I'm not completely happy with letting
> relative sitemap paths be opaque and absolute be hierarchical, but I
> don't see any better alternatives.
The thing is that the scheme specific part of the opaque URI, is
actually a relative URI which can be resolved against an absolute
one...
URI relative_uri =
absolute_uri.resolve(opaque_uri.getSchemeSpecificPart());
As simple as that...
>
> Concerning:
>
> block:super://blah.xml
>
> it is AFAICS a correct opaque URI. But we could make better use of
> java.net.URI if we considered a hierarchial URI scheme for blocks
> instead. From this perspective the scheme that Reinhard suggested
> makes sense
>
> block://portal/foo
>
> for refering to the absoute path "/foo" within the portal block,
>
> block:/foo
>
> for refering to the absolute path "/foo" within the current block and
>
> block:./bar
>
> for refering to the relative path "bar" relative to the current
> (sub)sitemap within the current block and
>
> block:super:/foo
>
> for refering to the absolute path "foo" whithin the super block of the
> current and possibly
>
> block:super:./bar
>
> for refering to the relative path "bar" relative to the current
> (sub)sitemap within the super block of the current.
>
> The last three URIs are opaque and could be resolved to absolute
> hierarchical URIs with a similar algorithm as you proposed for
> "cocoon:./" resolution.
>
> Maybe using "//portal" as an authority is stretching the intepretation
> to far.
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...
> Using an URIs like the ones above has the advantage that we can reuse
> most of the definition of hierarchial URIs and the functionality in
> java.net.URI, if we instead go for the opaque style exemplified by
> "block:super://blah.xml" we have to define the URI parsing ourselves
> instead.
The only problem I have with "block:super://blah.xml" is that "//" in
an URI indicates the start of the authority part, and this is defined
as "user@host:port", and no matter how you see it,
"block:...anything..." _is_ a URI, and thus should follow its spec...
Pier
>
> --- o0o ---
>
> As all URI discussions tend to provoke strong feelings for Stefano,
> it's best to say directly that this question is not important enough
> for me to fight about ;)
>
> But anyway, whether we go for an opaque custom protocol or base the
> block protocol on hierachial URIs we need to get into the specifics
> for the block URI scheme to be able to implement it.
>
> WDYT?
>
> /Daniel
>
>
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
>
> Anyhow, feel free to discuss it here...
I read your rant and agree with it, it seem benefical to take advantage
of java.net.URI. I'm not completely happy with letting relative sitemap
paths be opaque and absolute be hierarchical, but I don't see any better
alternatives.
Concerning:
block:super://blah.xml
it is AFAICS a correct opaque URI. But we could make better use of
java.net.URI if we considered a hierarchial URI scheme for blocks
instead. From this perspective the scheme that Reinhard suggested makes
sense
block://portal/foo
for refering to the absoute path "/foo" within the portal block,
block:/foo
for refering to the absolute path "/foo" within the current block and
block:./bar
for refering to the relative path "bar" relative to the current
(sub)sitemap within the current block and
block:super:/foo
for refering to the absolute path "foo" whithin the super block of the
current and possibly
block:super:./bar
for refering to the relative path "bar" relative to the current
(sub)sitemap within the super block of the current.
The last three URIs are opaque and could be resolved to absolute
hierarchical URIs with a similar algorithm as you proposed for
"cocoon:./" resolution.
Maybe using "//portal" as an authority is stretching the intepretation
to far.
Using an URIs like the ones above has the advantage that we can reuse
most of the definition of hierarchial URIs and the functionality in
java.net.URI, if we instead go for the opaque style exemplified by
"block:super://blah.xml" we have to define the URI parsing ourselves
instead.
--- o0o ---
As all URI discussions tend to provoke strong feelings for Stefano, it's
best to say directly that this question is not important enough for me
to fight about ;)
But anyway, whether we go for an opaque custom protocol or base the
block protocol on hierachial URIs we need to get into the specifics for
the block URI scheme to be able to implement it.
WDYT?
/Daniel
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Colin Paul Adams wrote:
>>>>>>"Daniel" == Daniel Fagerstrom <da...@nada.kth.se> writes:
>
>
> Daniel> cocoon:foo/bar
>
> Daniel> where "foo/bar" is called a root less path. But I don't
> Daniel> find any explanation about what it is supposed to mean.
>
> Well, it could mean anything the protocol inventor intended.
> Not all URI schemes are hierarchical in nature. This does not mean
> they cannot use the / character.
Thing is that foo/bar in the example above actually is supposed to be a
hierarchy consisting of the segments foo and bar according to rfc3986.
But after having checked it closer, the comment in the end of chapter 5
seem to mean that is shouldn't be used and only is part of the spec to
cover a loophole in rfc1630 the predecessor of rfc2396. So we shouldn't
use it anyway.
/Daniel
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Daniel" == Daniel Fagerstrom <da...@nada.kth.se> writes:
Daniel> cocoon:foo/bar
Daniel> where "foo/bar" is called a root less path. But I don't
Daniel> find any explanation about what it is supposed to mean.
Well, it could mean anything the protocol inventor intended.
Not all URI schemes are hierarchical in nature. This does not mean
they cannot use the / character.
--
Colin Paul Adams
Preston Lancashire
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> Colin Paul Adams wrote:
>
>>>>>>> "Pier" == Pier Fumagalli <pi...@betaversion.org> writes:
>>>>>>>
>>
>>
>> Pier> I'm already slightly "upset" about the "cocoon://" protocol,
>> Pier> as it does not follow the URI RFC properly, I'd like to
>> Pier> address the problem as early as possible...
>>
>> Pier> http://www.ietf.org/rfc/rfc2396.txt
>>
>> I don't know if this is relevant to the discussion, but are you aware
>> that this RFC has been obsoleted by RFC 3986?
>>
>>
> It has some relevance to the discussion as it seem (chap 3.) to allow a
> hierarchical URI at the form:
>
> cocoon:foo/bar
>
> where "foo/bar" is called a root less path. But I don't find any
> explanation about what it is supposed to mean.
that's the point of a general URI syntax: the meaning is not defined.
It's just XML for strings really. The semantics are not defined there.
--
Stefano.
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Colin Paul Adams wrote:
>>>>>>"Pier" == Pier Fumagalli <pi...@betaversion.org> writes:
>>>>>>
>>>>>>
>
> Pier> I'm already slightly "upset" about the "cocoon://" protocol,
> Pier> as it does not follow the URI RFC properly, I'd like to
> Pier> address the problem as early as possible...
>
> Pier> http://www.ietf.org/rfc/rfc2396.txt
>
>I don't know if this is relevant to the discussion, but are you aware
>that this RFC has been obsoleted by RFC 3986?
>
>
It has some relevance to the discussion as it seem (chap 3.) to allow a
hierarchical URI at the form:
cocoon:foo/bar
where "foo/bar" is called a root less path. But I don't find any
explanation about what it is supposed to mean.
/Daniel
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 4 Apr 2005, at 18:09, Colin Paul Adams wrote:
>>>>>> "Pier" == Pier Fumagalli <pi...@betaversion.org> writes:
>
> Pier> I'm already slightly "upset" about the "cocoon://" protocol,
> Pier> as it does not follow the URI RFC properly, I'd like to
> Pier> address the problem as early as possible...
>
> Pier> http://www.ietf.org/rfc/rfc2396.txt
>
> I don't know if this is relevant to the discussion, but are you aware
> that this RFC has been obsoleted by RFC 3986?
Ups, didn't pick up that one... Thanks... AFAICS the main changes
concern IPv6, anyhow... The overall concept remains the same.
Pier
Re: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Posted by Colin Paul Adams <co...@colina.demon.co.uk>.
>>>>> "Pier" == Pier Fumagalli <pi...@betaversion.org> writes:
Pier> I'm already slightly "upset" about the "cocoon://" protocol,
Pier> as it does not follow the URI RFC properly, I'd like to
Pier> address the problem as early as possible...
Pier> http://www.ietf.org/rfc/rfc2396.txt
I don't know if this is relevant to the discussion, but are you aware
that this RFC has been obsoleted by RFC 3986?
--
Colin Paul Adams
Preston Lancashire