Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Saturday, Sep 20, 2003, at 23:30 Europe/Rome, Geoff Howard wrote:

Stefano Mazzocchi wrote:

On Saturday, Sep 20, 2003, at 04:34 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:

On Thursday, Sep 18, 2003, at 04:51 Europe/Rome, Geoff Howard wrote:

Stefano Mazzocchi wrote:

I wasn't sure what uses component meant functionally.
the blocks declares what component is going to use from that block 
and will name it. This is the inverse of the cocoon.xroles file but 
does the same thing, providing a shorthand version of the role 
identifier in the context of that block.
So, what does a block use from another block if not a component?
pipelines and virtual pipeline components
Ok.  pipelines if a sitemap is declared, and virtual pipeline 
components
if they are provide-ed or exposed.
Hmmm, you made me realize that it's not clear how block can provide 
virtual pipeline components if a sitemap is not declared.

what do you people think about this?

Also below though they expose files (xsl)...

 I've
been thinking that neither file resources or classes would be 
accessible
directly.
yep
But from the example below there's obviously a shade of meaning in 
accessible directly.  They are accessible through the block 
protocol, no?
yes, but never *directly*. see below.

So all that's left is components (either sitemap components
or no)? (ah, source resolving through block: protocol?)
the blocks carry three things:
 1) pipelines (called via the block: protocol)
 2) avalon components (accessed via the component manager)
 3) pipeline virtual components (declared in your sitemap)
and file resources as below?
as reading pipelines

In the example
what does the first block (@id=cob:mycompany.com/webmail/1.3.43) 
use
from cob:mycompany.com/skin aka external-skin?  I'd guess all 
that's
left is resolving sources through the block: protocol?
yep
  So this would
mean there's a block:external-skin which will probably be some xsl 
file?
no.
block:external-skin identifies the root of the URI space addressed by 
that block. You could do things like
 block:external-skin:/stylesheets/news2html.xslt
that would return a stylesheet. And so on.
So where is the fact that external-skin can be expected to provide 
/stylesheets/news2html.xslt recorded?  Is it implicit because the 
resource is actually there in the block?
no, that would create a contract on the file system layout of the 
block, which might be undesirable (just like the protected/public 
method you imply below)

Is it only available if a pipeline matches it (eg map:match 
pattern=stylesheets/news2html.xsltmap:read 
src=stylesheets.news2html.xslt... ).
yep. look that it's entirely possible to do a

 map:match pattern=*
  map:read src={1}/
 /map:match
and forget about it... but later, extending blocks don't necessarely 
have to follow the same file system approach (they might be already 
using that directories for something else!) but just have to overload 
the sitemap.

this gives more flexibility, file system decoupling and explicitness, 
as in the spirit of the sitemap.

Can it be assumed that any physical file resource in the block can be 
considered provided?
no and should not.

I think there may be a danger here, a parallel to the problem we face 
when public methods are arbitrarily overridden.
exactly.

The alternative would be some list of publicly available resources 
available through block:.  I'd guess we'll want to avoid anything 
other than public or private (declared or not declared) - i.e., no 
package private, no protected, etc.
that would be a duplication of what the sitemap can do by itself.

Oh, and while we're abusing the java analogy, how many implements 
and extends are allowed?  I'd think 1 each but I haven't thought it 
out.
one extends and many implements, as we follow Java in disallowing 
multiple inheritance (which would be painful to maintain).

 If it's a virtual component, would this need to be declared on both
the provider and requirer as a component?
Yes, because the virtual component doesn't have a java classname that 
can be used to uniquely identify it.
...

Sounds good.  You snuck in type=hidden-string by the way which 
raises the question: what are the allowable values of type?  string, 
integer,
hidden-string, (basic primitive values) or complex values like
phone-number or ip address?
KISS
No need to enumerate specifics now, but
the general concept might be good to address.  And is it extensible?
FS for now. Let's have String, Number and HiddenString. That should 
be enough, because the code should do checking at runtime anyway.
Sounds good.

...

The implements uri and the requires uri match up based on versioning
rules but are separate for wiring purposes from the @id.  But in the
scenario:
  cob:yetanothercompany.com/skins/fancy/1.2.2
implements - cob:mycompany.com/skin/1.2
  cob:mycompany.com/skins/corporate/34.3.345
implements - cob:mycompany.com/skin/2.3
extends - cob:yetanothercompany.com/skins/fancy/1.2.2
Does 

Re: [RT] Implementing Cocoon Blocks

[Bertrand Delacretaz]

Le Vendredi, 19 sep 2003, à 23:14 Europe/Zurich, Stefano Mazzocchi a 
écrit :

On Friday, Sep 19, 2003, at 19:31 Europe/Rome, Reinhard Poetz wrote:

From: Bertrand Delacretaz

Le Jeudi, 18 sep 2003, à 21:09 Europe/Zurich, Reinhard Poetz a écrit 
:

...I understand that I can't load a class from another block. My
question:
Is it possible to load classes from Cocoon core (whatever we will
consider as core) from within my block via new or are
there arguments
against it?...
I think loading classes directly via new (as opposed to factories +
interfaces) should be discouraged as much as possible, as it creates
unnecessary coupling.
Depending on the classloading mechanisms that are implemented,
selective filtering of what is allowed could be implemented easily I
think [1].
Do you have examples where direct instantation via new is required?
e.g. line 341 in the HTMLGenerator

   throw new ProcessingException(Exception in
HTMLGenerator.generate(),e);
(org.apache.cocoon.ProcessingException)

How can I do this in the generator in the future?
Of course!
Obviously - but still, do you want to let blocks access all public core 
classes openly?

Event if it's no needed right away, I think being able to filter this 
classloading from blocks to core should be planned for in the design 
(but maybe it is already?).

-Bertrand

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Saturday, Sep 20, 2003, at 10:03 Europe/Rome, Bertrand Delacretaz 
wrote:

Le Vendredi, 19 sep 2003, à 23:14 Europe/Zurich, Stefano Mazzocchi a 
écrit :

On Friday, Sep 19, 2003, at 19:31 Europe/Rome, Reinhard Poetz wrote:

From: Bertrand Delacretaz

Le Jeudi, 18 sep 2003, à 21:09 Europe/Zurich, Reinhard Poetz a 
écrit :

...I understand that I can't load a class from another block. My
question:
Is it possible to load classes from Cocoon core (whatever we will
consider as core) from within my block via new or are
there arguments
against it?...
I think loading classes directly via new (as opposed to factories +
interfaces) should be discouraged as much as possible, as it creates
unnecessary coupling.
Depending on the classloading mechanisms that are implemented,
selective filtering of what is allowed could be implemented easily I
think [1].
Do you have examples where direct instantation via new is 
required?
e.g. line 341 in the HTMLGenerator

   throw new ProcessingException(Exception in
HTMLGenerator.generate(),e);
(org.apache.cocoon.ProcessingException)

How can I do this in the generator in the future?
Of course!
Obviously - but still, do you want to let blocks access all public 
core classes openly?
Why not?

Event if it's no needed right away, I think being able to filter this 
classloading from blocks to core should be planned for in the design 
(but maybe it is already?).
The design doesn't need to specify this since it's a classloading 
implementation issue.

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Bertrand Delacretaz]

Le Samedi, 20 sep 2003, à 14:15 Europe/Zurich, Stefano Mazzocchi a 
écrit :
On Saturday, Sep 20, 2003, at 10:03 Europe/Rome, Bertrand Delacretaz 
wrote:
...Obviously - but still, do you want to let blocks access all public 
core classes openly?
Why not?
Making as little core classes available as possible will help in 
decoupling blocks from the core.

Java often forces you to make a class public so that it can be accessed 
from other packages, but in many cases this does not mean that the 
class should be used everywhere.


Event if it's no needed right away, I think being able to filter this 
classloading from blocks to core should be planned for in the design 
(but maybe it is already?).
The design doesn't need to specify this since it's a classloading 
implementation issue.
you're right, this does not need to be decided at this point.

-Bertrand

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Saturday, Sep 20, 2003, at 04:34 Europe/Rome, Geoff Howard wrote:

Stefano Mazzocchi wrote:

On Thursday, Sep 18, 2003, at 04:51 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:

I wasn't sure what uses component meant functionally.
the blocks declares what component is going to use from that block 
and will name it. This is the inverse of the cocoon.xroles file but 
does the same thing, providing a shorthand version of the role 
identifier in the context of that block.
So, what does a block use from another block if not a component?
pipelines and virtual pipeline components

 I've
been thinking that neither file resources or classes would be 
accessible
directly.
yep

So all that's left is components (either sitemap components
or no)? (ah, source resolving through block: protocol?)
the blocks carry three things:

 1) pipelines (called via the block: protocol)
 2) avalon components (accessed via the component manager)
 3) pipeline virtual components (declared in your sitemap)
In the example
what does the first block (@id=cob:mycompany.com/webmail/1.3.43) use
from cob:mycompany.com/skin aka external-skin?  I'd guess all that's
left is resolving sources through the block: protocol?
yep

  So this would
mean there's a block:external-skin which will probably be some xsl 
file?
no.

block:external-skin identifies the root of the URI space addressed by 
that block. You could do things like

 block:external-skin:/stylesheets/news2html.xslt

that would return a stylesheet. And so on.

 If it's a virtual component, would this need to be declared on both
the provider and requirer as a component?
Yes, because the virtual component doesn't have a java classname that 
can be used to uniquely identify it.

For the record, I hate dependencies and depends-on and I left 
them that way in the hope that they are so offensively bad that 
someone will think of a better one. :)
Ok, let me try again:
block xmlns=http://apache.org/cocoon/blocks/cob/1.0;
   id=cob:mycompany.com/webmail/1.3.43
  sitemap src=/webmail.xmap/
  requirements
   requires
   block=cob:mycompany.com/skin
   name=external-skin
   /
   requires
   block=cob:mycompany.com/skin/2.0
   name=internal-skin
   /
   requires
   block=cob.anothercompany.com/MailRepository/2.0
   name=repository
 uses
 component=com.anothercompany.repository.Repository
 name=repository
 /
   /requires
  requirements
  parameters
   param name=user type=string/
   param name=password type=hidden-string/
  /parameters
 /block
Sounds good.  You snuck in type=hidden-string by the way which 
raises the question: what are the allowable values of type?  string, 
integer,
hidden-string, (basic primitive values) or complex values like
phone-number or ip address?
KISS

No need to enumerate specifics now, but
the general concept might be good to address.  And is it extensible?
FS for now. Let's have String, Number and HiddenString. That should be 
enough, because the code should do checking at runtime anyway.

  cob:yetanothercompany.com/skins/fancy/1.2.2
implements - cob:mycompany.com/skin/1.2
cob xmlns=http://apache.org/cocoon/blocks/cob/1.0;
 uri=cob:yetanothercompany.com/skins/fancy/1.2.2
implements uri=cob:mycompany.com/skin/1.2/
/cob
do we implement a uri?
well, in theory, we implement the block behavior that is identified 
by that URI. So I would write it as
 block xmlns=http://apache.org/cocoon/blocks/cob/1.0;
id=cob:yetanothercompany.com/skins/fancy/1.2.2
   implements behavior=cob:mycompany.com/skin/1.2/
 /block
Ok, but we have now at least three different attribute names describing
the block uri/id: id, behavior, and block which may be harder to
remember and to identify that these things go together.  I'd propose
using only two:
- @id to identify the definition of the unique block element
- @block to refer to this id elsewhere. (alternatives: @behavior,
@contract ...)
Good point. +1

So that becomes
implements block=cob:mycompany.com/skin/1.2/

I'm not convinced of this, but wiki'd it that way just to try it out.
The distinction of @behavior and @block does kind of make sense to me
but here's a question:
The implements uri and the requires uri match up based on versioning
rules but are separate for wiring purposes from the @id.  But in the
scenario:
  cob:yetanothercompany.com/skins/fancy/1.2.2
implements - cob:mycompany.com/skin/1.2
  cob:mycompany.com/skins/corporate/34.3.345
implements - cob:mycompany.com/skin/2.3
extends - cob:yetanothercompany.com/skins/fancy/1.2.2
Does cob:mycompany.com/skins/corporate/34.3.345 also implicitly
implement cob:mycompany.com/skin/1.2 because it extends
cob:yetanothercompany.com/skins/fancy/1.2.2?
Not necessarely. Since cob:mycompany.com/skin/1.2 and 
cob:mycompany.com/skin/2.3 have different major version numbers, they 
are declared to be back incompatible. It could be that 
cob:mycompany.com/skins/corporate/34.3.345, in order to be implement 

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Stefano Mazzocchi wrote:

On Saturday, Sep 20, 2003, at 04:34 Europe/Rome, Geoff Howard wrote:

Stefano Mazzocchi wrote:

On Thursday, Sep 18, 2003, at 04:51 Europe/Rome, Geoff Howard wrote:

Stefano Mazzocchi wrote:

I wasn't sure what uses component meant functionally.
the blocks declares what component is going to use from that block 
and will name it. This is the inverse of the cocoon.xroles file but 
does the same thing, providing a shorthand version of the role 
identifier in the context of that block.
So, what does a block use from another block if not a component?
pipelines and virtual pipeline components
Ok.  pipelines if a sitemap is declared, and virtual pipeline components
if they are provide-ed or exposed.
Also below though they expose files (xsl)...

 I've
been thinking that neither file resources or classes would be accessible
directly.
yep
But from the example below there's obviously a shade of meaning in 
accessible directly.  They are accessible through the block protocol, no?

So all that's left is components (either sitemap components
or no)? (ah, source resolving through block: protocol?)
the blocks carry three things:

 1) pipelines (called via the block: protocol)
 2) avalon components (accessed via the component manager)
 3) pipeline virtual components (declared in your sitemap)
and file resources as below?

In the example
what does the first block (@id=cob:mycompany.com/webmail/1.3.43) use
from cob:mycompany.com/skin aka external-skin?  I'd guess all that's
left is resolving sources through the block: protocol?
yep

  So this would
mean there's a block:external-skin which will probably be some xsl file?
no.

block:external-skin identifies the root of the URI space addressed by 
that block. You could do things like

 block:external-skin:/stylesheets/news2html.xslt

that would return a stylesheet. And so on.
So where is the fact that external-skin can be expected to provide 
/stylesheets/news2html.xslt recorded?  Is it implicit because the 
resource is actually there in the block?  Is it only available if a 
pipeline matches it (eg map:match 
pattern=stylesheets/news2html.xsltmap:read 
src=stylesheets.news2html.xslt... ).  Can it be assumed that any 
physical file resource in the block can be considered provided?

I think there may be a danger here, a parallel to the problem we face 
when public methods are arbitrarily overridden.

The alternative would be some list of publicly available resources 
available through block:.  I'd guess we'll want to avoid anything 
other than public or private (declared or not declared) - i.e., no 
package private, no protected, etc.

Oh, and while we're abusing the java analogy, how many implements and 
extends are allowed?  I'd think 1 each but I haven't thought it out.

 If it's a virtual component, would this need to be declared on both
the provider and requirer as a component?
Yes, because the virtual component doesn't have a java classname that 
can be used to uniquely identify it.
...

Sounds good.  You snuck in type=hidden-string by the way which 
raises the question: what are the allowable values of type?  string, 
integer,
hidden-string, (basic primitive values) or complex values like
phone-number or ip address?
KISS

No need to enumerate specifics now, but
the general concept might be good to address.  And is it extensible?
FS for now. Let's have String, Number and HiddenString. That should be 
enough, because the code should do checking at runtime anyway.
Sounds good.

...

The implements uri and the requires uri match up based on versioning
rules but are separate for wiring purposes from the @id.  But in the
scenario:
  cob:yetanothercompany.com/skins/fancy/1.2.2
implements - cob:mycompany.com/skin/1.2
  cob:mycompany.com/skins/corporate/34.3.345
implements - cob:mycompany.com/skin/2.3
extends - cob:yetanothercompany.com/skins/fancy/1.2.2
Does cob:mycompany.com/skins/corporate/34.3.345 also implicitly
implement cob:mycompany.com/skin/1.2 because it extends
cob:yetanothercompany.com/skins/fancy/1.2.2?
Not necessarely. Since cob:mycompany.com/skin/1.2 and 
cob:mycompany.com/skin/2.3 have different major version numbers, they 
are declared to be back incompatible. It could be that 
cob:mycompany.com/skins/corporate/34.3.345, in order to be implement 
cob:mycompany.com/skin/2.3 had to overload a few URIs from 
cob:yetanothercompany.com/skins/fancy/1.2.2 whose behavior would not be 
compliant to implements - cob:mycompany.com/skin/1.2.

For example, say cob:mycompany.com/skin/1.2 includes 
/stylesheets/news2html.xslt and /stylesheet/doc2html.xslt.

The first, by default, strips all content that doesn't belong to the 
news markup language. cob:yetanothercompany.com/skins/fancy/1.2.2 
implements this behavior.

Later, a new need is identified (for whatever reason) and the behavior 
of news2html.xslt is changed so that content in different namespaces is 
copied over. Clearly, this is a back-incompatible change and this 
required an 

Re: [RT] Implementing Cocoon Blocks

[Bertrand Delacretaz]

Le Jeudi, 18 sep 2003, à 21:09 Europe/Zurich, Reinhard Poetz a écrit :

...I understand that I can't load a class from another block. My  
question:
Is it possible to load classes from Cocoon core (whatever we will
consider as core) from within my block via new or are there arguments
against it?...
I think loading classes directly via new (as opposed to factories +  
interfaces) should be discouraged as much as possible, as it creates  
unnecessary coupling.

Depending on the classloading mechanisms that are implemented,  
selective filtering of what is allowed could be implemented easily I  
think [1].

Do you have examples where direct instantation via new is required?

-Bertrand

[1] see discussion of a FirewallClassLoader in  
http://www.theserverside.com/resources/articles/AdvancedClassLoading/ 
article.html

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Thursday, Sep 18, 2003, at 21:09 Europe/Rome, Reinhard Poetz wrote:

From: Stefano Mazzocchi

snip/

  3) persistent service behavior with hot deployment

One of the big issues with hot deployment is the potentially
inconsistent state of the persistent services contained by one block
and used by another when the providing block is redeployed.
The issue is easily solvable for block services provided via
sitemap by
imposing them as stateless services (or REST-like, by passing all the
required information every time).
The problem appears evident for component instances.

It is suggested that blocks don't allow direct classloading between
blocks, but that only components exposed in the block deployment
descriptor will be made available to other blocks. This way, all the
dependencies are known because all the component loading happens thru
the Block Manager and the block manager is able disposte and
reinstantiate all the blocks that contain instances of
components that
are in an inconsistent state.
While it is possible to write a classloader which is smart
enough to do
the above even for transparent classloading (say, loading via new
Blah() instead of via cocoon.getComponent(Blah)), it is
suggested to
disallow direct classloading to avoid creating hidden
contracts between
blocks.
I understand that I can't load a class from another block. My question:
Is it possible to load classes from Cocoon core (whatever we will
consider as core) from within my block via new or are there arguments
against it?
At least one block will need it: the block deployer webapp block. 
There could be stuff like the restarting block that allows cocoon to 
be restarted from a web page (useful for debugging), or stuff like that.

It is entirely possible to prevent the blocks from having access to 
some classes down under (as bertrand showed) but it might be very hard 
to audit the security of such a scheme.

I'd prefer leave it open and suggest that people use blocks from 
sources they trust. [we will provide digital signing of our blocks to 
avoid trojan problems]

Running a block in a security sandbox is, IMO, way too much, since the 
naked cocoon itself will be sandboxed by the container anyway, so a 
trojan block will not be able to do anything more than a cocoon would 
and the appserver will do the security policy for us.

the only potential issue is for people that run different coocon 
applications in the same cocoon instance and want to isolate them since 
the data flowing in belong to different users (say an ISP) but it would 
be pretty lame if they did so using teh same cocoon instance (people 
normally install different JVM as they don't trust the java security 
manager)

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Thursday, Sep 18, 2003, at 04:51 Europe/Rome, Geoff Howard wrote:

Stefano Mazzocchi wrote:

Ok, after reaching some stasis on wiring.xml, starting the discussion 
on cob.xml (or whatever).  I expect that both of these will be much 
more interesting discussions after real implementation starts.

 Implementation Phases
 -

 Phase 1: definition of the contract between the block manager inside
 cocoon and the standalone block deployer. These contracts include:
...
  3) description of the block metadata schema
So, here's a proposed simple xml version (each xml snippet would be 
it's own cob.xml of course):

File System Layout and wiring data
--
Let us suppose we have the following blocks that are deployed in our 
system
  cob:mycompany.com/webmail/1.3.43
   has a sitemap located on - /webmail.xmap
   depends on - cob:mycompany.com/skin
 names this dependency - external-skin
   depends on - cob:mycompany.com/skin/2.0
 names this dependency - internal-skin
   depends on - cob:anothercompany.com/MailRepository/2.0
 names this dependency - repository
 uses component - com.anothercompany.repository.Repository
   names this component with role - repository
   requires the configurations:
 user of type string with no default
 password of type string with no default
cob xmlns=http://apache.org/cocoon/blocks/cob/1.0;
 uri=cob:mycompany.com/webmail/1.3.43
   sitemap src=/webmail.xmap/
   dependencies
 depends-on uri  =cob:mycompany.com/skin
   name =external-skin  /
 depends-on uri  =cob:mycompany.com/skin/2.0
   name =internal-skin  /
 depends-on uri  =cob:anothercompany.com/MailRepository/2.0
   name =repository  
   component role=com.anothercompany.repository.Repository
name=repository/
 /depends-on
   /dependencies
   parameters
 param name=user type=string /
 param name=password type=string /
   /parameters
/cob
I'm assuming here that:
- all parameters will be required and declaring them with no @default 
will force the deployer to supply a value.
yes

- the sitemap element will force the deploy process to prompt for a 
mount point (we may want to allow for a default suggested one)
correct.

I wasn't sure what uses component meant functionally.
the blocks declares what component is going to use from that block and 
will name it. This is the inverse of the cocoon.xroles file but does 
the same thing, providing a shorthand version of the role identifier in 
the context of that block.

For the record, I hate dependencies and depends-on and I left them 
that way in the hope that they are so offensively bad that someone 
will think of a better one. :)
Ok, let me try again:

block xmlns=http://apache.org/cocoon/blocks/cob/1.0;
   id=cob:mycompany.com/webmail/1.3.43
  sitemap src=/webmail.xmap/
  requirements
   requires
   block=cob:mycompany.com/skin
   name=external-skin
   /
   requires
   block=cob:mycompany.com/skin/2.0
   name=internal-skin
   /
   requires
   block=cob.anothercompany.com/MailRepository/2.0
   name=repository
 uses
 component=com.anothercompany.repository.Repository
 name=repository
 /
   /requires
  requirements
  parameters
   param name=user type=string/
   param name=password type=hidden-string/
  /parameters
 /block
  cob:yetanothercompany.com/skins/fancy/1.2.2
implements - cob:mycompany.com/skin/1.2
cob xmlns=http://apache.org/cocoon/blocks/cob/1.0;
 uri=cob:yetanothercompany.com/skins/fancy/1.2.2
implements uri=cob:mycompany.com/skin/1.2/
/cob

do we implement a uri?
well, in theory, we implement the block behavior that is identified by 
that URI. So I would write it as

 block xmlns=http://apache.org/cocoon/blocks/cob/1.0;
id=cob:yetanothercompany.com/skins/fancy/1.2.2
   implements behavior=cob:mycompany.com/skin/1.2/
 /block
Is it right to specify the whole version here and let the versioning 
rules specified in the RT work out that this satisfies depends-on 
uri=cob:mycompany.com/skin name=external-skin/ from above?
yes. you need to specify *exactly* what behavior you are implementing. 
you cannot implement a range of behaviors, that can potentially lead to 
inconsistent states.

  cob:mycompany.com/skins/corporate/34.3.345
implements - cob:mycompany.com/skin/2.3
extends - cob:yetanothercompany.com/skins/fancy/1.2.2
cob xmlns=http://apache.org/cocoon/blocks/cob/1.0;
 uri=cob:mycompany.com/skins/corporate/34.3.345
implements uri=cob:mycompany.com/skin/2.3/
extends uri=cob:yetanothercompany.com/skins/fancy/1.2.2/
/cob
Extends is introduced here, same questions as implements.
extends block=cob:yetanothercompany.com/skins/fancy/1.2.2/

same as above

  cob:mycompany.com/repositories/email/exchange/3.2.1
implements - cob:anothercompany.com/MailRepository/2.0
exposes component - com.anothercompany.repository.Repository
   

RE: [RT] Implementing Cocoon Blocks

[Reinhard Poetz]

From: Bertrand Delacretaz

 Le Jeudi, 18 sep 2003, à 21:09 Europe/Zurich, Reinhard Poetz a écrit :
 
  ...I understand that I can't load a class from another block. My
  question:
  Is it possible to load classes from Cocoon core (whatever we will
  consider as core) from within my block via new or are 
 there arguments
  against it?...
 
 I think loading classes directly via new (as opposed to factories +  
 interfaces) should be discouraged as much as possible, as it creates  
 unnecessary coupling.
 
 Depending on the classloading mechanisms that are implemented,  
 selective filtering of what is allowed could be implemented easily I  
 think [1].
 
 Do you have examples where direct instantation via new is required?

e.g. line 341 in the HTMLGenerator 

   throw new ProcessingException(Exception in
HTMLGenerator.generate(),e);

(org.apache.cocoon.ProcessingException)

How can I do this in the generator in the future?

Cheers,
Reinhard

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Friday, Sep 19, 2003, at 19:31 Europe/Rome, Reinhard Poetz wrote:

From: Bertrand Delacretaz

Le Jeudi, 18 sep 2003, à 21:09 Europe/Zurich, Reinhard Poetz a écrit :

...I understand that I can't load a class from another block. My
question:
Is it possible to load classes from Cocoon core (whatever we will
consider as core) from within my block via new or are
there arguments
against it?...
I think loading classes directly via new (as opposed to factories +
interfaces) should be discouraged as much as possible, as it creates
unnecessary coupling.
Depending on the classloading mechanisms that are implemented,
selective filtering of what is allowed could be implemented easily I
think [1].
Do you have examples where direct instantation via new is required?
e.g. line 341 in the HTMLGenerator

   throw new ProcessingException(Exception in
HTMLGenerator.generate(),e);
(org.apache.cocoon.ProcessingException)

How can I do this in the generator in the future?
Of course!

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Stefano Mazzocchi wrote:

On Thursday, Sep 18, 2003, at 04:51 Europe/Rome, Geoff Howard wrote:

Stefano Mazzocchi wrote:

I wasn't sure what uses component meant functionally.
the blocks declares what component is going to use from that block and 
will name it. This is the inverse of the cocoon.xroles file but does the 
same thing, providing a shorthand version of the role identifier in the 
context of that block.
So, what does a block use from another block if not a component?  I've
been thinking that neither file resources or classes would be accessible
directly.  So all that's left is components (either sitemap components
or no)? (ah, source resolving through block: protocol?)  In the example
what does the first block (@id=cob:mycompany.com/webmail/1.3.43) use
from cob:mycompany.com/skin aka external-skin?  I'd guess all that's
left is resolving sources through the block: protocol?  So this would
mean there's a block:external-skin which will probably be some xsl file?
 If it's a virtual component, would this need to be declared on both
the provider and requirer as a component?
For the record, I hate dependencies and depends-on and I left them 
that way in the hope that they are so offensively bad that someone 
will think of a better one. :)
Ok, let me try again:
block xmlns=http://apache.org/cocoon/blocks/cob/1.0;
   id=cob:mycompany.com/webmail/1.3.43
  sitemap src=/webmail.xmap/
  requirements
   requires
   block=cob:mycompany.com/skin
   name=external-skin
   /
   requires
   block=cob:mycompany.com/skin/2.0
   name=internal-skin
   /
   requires
   block=cob.anothercompany.com/MailRepository/2.0
   name=repository
 uses
 component=com.anothercompany.repository.Repository
 name=repository
 /
   /requires
  requirements
  parameters
   param name=user type=string/
   param name=password type=hidden-string/
  /parameters
 /block
Sounds good.  You snuck in type=hidden-string by the way which raises 
the question: what are the allowable values of type?  string, integer,
hidden-string, (basic primitive values) or complex values like
phone-number or ip address?  No need to enumerate specifics now, but
the general concept might be good to address.  And is it extensible?

  cob:yetanothercompany.com/skins/fancy/1.2.2
implements - cob:mycompany.com/skin/1.2
cob xmlns=http://apache.org/cocoon/blocks/cob/1.0;
 uri=cob:yetanothercompany.com/skins/fancy/1.2.2
implements uri=cob:mycompany.com/skin/1.2/
/cob

do we implement a uri?
well, in theory, we implement the block behavior that is identified by 
that URI. So I would write it as

 block xmlns=http://apache.org/cocoon/blocks/cob/1.0;
id=cob:yetanothercompany.com/skins/fancy/1.2.2
   implements behavior=cob:mycompany.com/skin/1.2/
 /block
Ok, but we have now at least three different attribute names describing
the block uri/id: id, behavior, and block which may be harder to
remember and to identify that these things go together.  I'd propose
using only two:
- @id to identify the definition of the unique block element
- @block to refer to this id elsewhere. (alternatives: @behavior,
@contract ...)
So that becomes
implements block=cob:mycompany.com/skin/1.2/
I'm not convinced of this, but wiki'd it that way just to try it out.
The distinction of @behavior and @block does kind of make sense to me
but here's a question:
The implements uri and the requires uri match up based on versioning
rules but are separate for wiring purposes from the @id.  But in the
scenario:
  cob:yetanothercompany.com/skins/fancy/1.2.2
implements - cob:mycompany.com/skin/1.2
  cob:mycompany.com/skins/corporate/34.3.345
implements - cob:mycompany.com/skin/2.3
extends - cob:yetanothercompany.com/skins/fancy/1.2.2
Does cob:mycompany.com/skins/corporate/34.3.345 also implicitly
implement cob:mycompany.com/skin/1.2 because it extends
cob:yetanothercompany.com/skins/fancy/1.2.2?
Also, does the fact that no component initially defining
cob:anothercompany.com/MailRepository/2.0 exists here matter?
With this and the above questions I'm trying to get at where the hidden
contracts are.
Is it right to specify the whole version here and let the versioning 
rules specified in the RT work out that this satisfies depends-on 
uri=cob:mycompany.com/skin name=external-skin/ from above?
yes. you need to specify *exactly* what behavior you are implementing. 
you cannot implement a range of behaviors, that can potentially lead to 
inconsistent states.
ok

...

provides role=com.anothercompany.repository.Repository/
change role to component? [role is avalon terminology and might confuse 
non-avaloners]
I'm ok either way.  I think role is very easy to grasp as the more
general concept and component could get confused between the role and
the implementation of that role.  Still, I've wiki'd it with component
for now unless you or others find that argument compelling.
Here's the provides which might also be exposes.
both are 

RE: [RT] Implementing Cocoon Blocks

[Reinhard Poetz]

From: Stefano Mazzocchi

snip/

   3) persistent service behavior with hot deployment
 
 One of the big issues with hot deployment is the potentially 
 inconsistent state of the persistent services contained by one block 
 and used by another when the providing block is redeployed.
 
 The issue is easily solvable for block services provided via 
 sitemap by 
 imposing them as stateless services (or REST-like, by passing all the 
 required information every time).
 
 The problem appears evident for component instances.
 
 It is suggested that blocks don't allow direct classloading between 
 blocks, but that only components exposed in the block deployment 
 descriptor will be made available to other blocks. This way, all the 
 dependencies are known because all the component loading happens thru 
 the Block Manager and the block manager is able disposte and 
 reinstantiate all the blocks that contain instances of 
 components that 
 are in an inconsistent state.
 
 While it is possible to write a classloader which is smart 
 enough to do 
 the above even for transparent classloading (say, loading via new 
 Blah() instead of via cocoon.getComponent(Blah)), it is 
 suggested to 
 disallow direct classloading to avoid creating hidden 
 contracts between 
 blocks.

I understand that I can't load a class from another block. My question:
Is it possible to load classes from Cocoon core (whatever we will
consider as core) from within my block via new or are there arguments
against it?

Reinhard

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Stefano Mazzocchi wrote:

Ok, after reaching some stasis on wiring.xml, starting the discussion on 
cob.xml (or whatever).  I expect that both of these will be much more 
interesting discussions after real implementation starts.

 Implementation Phases
 -

 Phase 1: definition of the contract between the block manager inside
 cocoon and the standalone block deployer. These contracts include:
...
  3) description of the block metadata schema
So, here's a proposed simple xml version (each xml snippet would be it's 
own cob.xml of course):

File System Layout and wiring data
--
Let us suppose we have the following blocks that are deployed in our system

  cob:mycompany.com/webmail/1.3.43
   has a sitemap located on - /webmail.xmap
   depends on - cob:mycompany.com/skin
 names this dependency - external-skin
   depends on - cob:mycompany.com/skin/2.0
 names this dependency - internal-skin
   depends on - cob:anothercompany.com/MailRepository/2.0
 names this dependency - repository
 uses component - com.anothercompany.repository.Repository
   names this component with role - repository
   requires the configurations:
 user of type string with no default
 password of type string with no default
cob xmlns=http://apache.org/cocoon/blocks/cob/1.0;
 uri=cob:mycompany.com/webmail/1.3.43
   sitemap src=/webmail.xmap/
   dependencies
 depends-on uri  =cob:mycompany.com/skin
   name =external-skin  /
 depends-on uri  =cob:mycompany.com/skin/2.0
   name =internal-skin  /
 depends-on uri  =cob:anothercompany.com/MailRepository/2.0
   name =repository  
   component role=com.anothercompany.repository.Repository
name=repository/
 /depends-on
   /dependencies
   parameters
 param name=user type=string /
 param name=password type=string /
   /parameters
/cob
I'm assuming here that:
- all parameters will be required and declaring them with no @default 
will force the deployer to supply a value.
- the sitemap element will force the deploy process to prompt for a 
mount point (we may want to allow for a default suggested one)

I wasn't sure what uses component meant functionally.

For the record, I hate dependencies and depends-on and I left them 
that way in the hope that they are so offensively bad that someone will 
think of a better one. :)


  cob:yetanothercompany.com/skins/fancy/1.2.2
implements - cob:mycompany.com/skin/1.2
cob xmlns=http://apache.org/cocoon/blocks/cob/1.0;
 uri=cob:yetanothercompany.com/skins/fancy/1.2.2
implements uri=cob:mycompany.com/skin/1.2/
/cob
do we implement a uri?  Is it right to specify the whole version here 
and let the versioning rules specified in the RT work out that this 
satisfies depends-on uri=cob:mycompany.com/skin 
name=external-skin/ from above?

  cob:mycompany.com/skins/corporate/34.3.345
implements - cob:mycompany.com/skin/2.3
extends - cob:yetanothercompany.com/skins/fancy/1.2.2
cob xmlns=http://apache.org/cocoon/blocks/cob/1.0;
 uri=cob:mycompany.com/skins/corporate/34.3.345
implements uri=cob:mycompany.com/skin/2.3/
extends uri=cob:yetanothercompany.com/skins/fancy/1.2.2/
/cob
Extends is introduced here, same questions as implements.

  cob:mycompany.com/repositories/email/exchange/3.2.1
implements - cob:anothercompany.com/MailRepository/2.0
exposes component - com.anothercompany.repository.Repository
requires the configurations:
 host of type string, with default 127.0.0.1
cob xmlns=http://apache.org/cocoon/blocks/cob/1.0;
 uri=cob:mycompany.com/repositories/email/exchange/3.2.1
implements uri=cob:anothercompany.com/MailRepository/2.0/
provides role=com.anothercompany.repository.Repository/
parameters
  param name=host type=string default=127.0.0.1 /
/parameters
/cob
Here's the provides which might also be exposes.  Also, here's an 
example of a default provided for a param.  During install, the block 
manager would prompt the admin to provide a value but would not be 
required because a default is given.

http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob

Geoff

RE: [RT] Implementing Cocoon Blocks

[Hunsberger, Peter]

Stefano Mazzocchi [EMAIL PROTECTED] writes:

  The more I  watch this discussion go by the more I feel 
 like Cocoon is 
  reinventing JBoss.
 
 you are noting convergence of applying the same patterns onto two 
 different domains. all operating systems have a file system, but this 
 doesn't make them all the same thing.
 
  The more I watch the Aspects discussion go by the
  more I feel like Cocoon is reinventing JBoss.
 
 same convergence again. all server side environments have 
 crosscutting 
 concerns, that will require similar solutions.
 
  Too bad JBoss isn't a
  container that we can just pick up for Cocoon and count on
 
 I would be very glad to use something that already exists rather than 
 reinventing the wheel. but I really see no way on making 
 cocoon work on 
 top of jboss and apply its modularization facility to 
 polymorphic block 
 deployment and its AOP framework on allow our continuation-based 
 flowscript to be interceptable.
 
 if you have any idea on how to do this, I'm all ears. even if 
 the point 
 is academic since we can't ship jboss with cocoon.

My comments where more wistful/rhetorical than anything else.   However,
the one thing we might want to look at is how JBoss implements
interceptions.  In particular, it has an XML configuration file that can
be used to specify how any Java code running under it is intercepted
(and in fact the interception engine is independent of JBoss).  Even if
we can't use the JBoss code perhaps we can support the same format for
configuring interceptions?

 
  BTW, On the same issue more or less: I don't think you ever 
 responded
  to
  my question on what to do for a container for EJB samples 
 supplied with
  Cocoon?  (Still trying to get permission to contribute our code.)
 
 we can't ship jboss since it's LGPLed. this is not going to change in 
 the future.
 
 we can wait for Geronimo to get real.

Given how slowly getting permission to release our code is crawling
along that might actually happen first (sigh)...

Re: [RT] Implementing Cocoon Blocks

[Vadim Gritsenko]

Stefano Mazzocchi wrote:

On Friday, Aug 29, 2003, at 18:27 Europe/Rome, Vadim Gritsenko wrote:

Temp dir:
I've been assuming this file and dir structure is the persistent 
state for the block manager.


The only servlet engine which wipes out deployment (aka temp, aka 
staging) directory on restart is Jetty. None of the others known to 
me do this.


yes, but the spec says that temp is not guaranteed to stay. I don't 
want to base such a key functionality on something that is not rock 
solid and temp directories for servlet contexts are designed not to be.


Ok.


If it has deployed the blocks, it records its state in this 
structure.  At Cocoon restart, this structure (wiring.xml and 
resulting filesystem tree) is used to initialize the 
blocks/components/etc. Otherwise the block deployer has to re-deploy 
everything on restart.  Have I got that right?


Remember, Cocoon is deployed here as a webapp.


Remember: when cocoon has blocks, you would *not* need to use a war in 
your life anymore for cocoon, only for the naked-cocoon.war file. the 
rest (even cluster replication) will be handled by the block deployer 
tool. [at least, that's my dream]


But, it still should be *able* to work as a war, isn't it?


And webapp can be archived into the war file. Now the question: how 
funny (e.g. 384938958499) directories get into the war file in the 
first place?


yes, they would appear funny, but keep in mind that those names are 
given by the block deployer.


That's what I meant, i.e. funny == generated.


if you wish to have proper names, that would be a comman line property 
away. This, for example, is useful for those projects that might wish 
to still distribute a complete war (forrest comes to mind) where the 
wiring.xml file is generated at build time.


So the answer will be then: those directories are generated during build 
time. Is there a way to drop in block into expanded war and have block 
deployer pick it up? Deployer will have to then pick up block from some 
directory, generate 123456789 directory, and unpack block there, all in 
runtime, after the build time.



Unpacked blocks:
Good question -- maybe in WEB-INF/blocks ?


I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc 
them into $temp/blocks, where $temp is temporary directory configured 
in web.xml. WEB-INF/blocks/ can also have blocks.xml to point out to 
blocks which are located outside of the blocks directory, for 
development needs.


that might be a solution, but would force us to consider blocks 
read-only because, otherwise, if a block writes something on its 
internal file system, that content is not guaranteed to be persistent.


We can either provide block deploy directory which will not be dependent 
on container behavior (like we allow specifying work directory in 
web.xml), or provide block temp directory.


I agree that you shouldn't store content in your block file system, 
but, hey, the servlet API tried to enforce that with leaving up to the 
containers to unpack wars and failed (even weblogic had to surrender 
to war unpacking for that IO problem).

In theory, it's all nice and good to keep things separate. In practice 
(and I speak out of linotype) having a file system under your feet is 
a great RAD ability and I wouldn't want to see it going away).


I'm not trying to.

Vadim

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Sunday, Sep 14, 2003, at 18:31 Europe/Rome, Vadim Gritsenko wrote:

if you wish to have proper names, that would be a comman line 
property away. This, for example, is useful for those projects that 
might wish to still distribute a complete war (forrest comes to mind) 
where the wiring.xml file is generated at build time.
So the answer will be then: those directories are generated during 
build time.
It is entirely possible to create a build process that creates the 
wiring.xml file without using the block deploying tool. I think cocoon 
apps like Forrest/Lenya might want to choose two types of distribution: 
a big war with all the blocks pre-expanded and the wiring.xml generated 
at build time and another one as blocks to be deployed on top of an 
existing cocoon.

The first distribution is for those who don't have a cocoon already 
installed, the second will be for those who do.

 Is there a way to drop in block into expanded war and have block 
deployer pick it up?
It could be possible, but only if there is no polymorphic behavior 
associated to the dependencies of that block. Otherwise, human 
intervention to choose which block implementation would implement the 
required block behavior cannot be avoided.

Deployer will have to then pick up block from some directory, generate 
123456789 directory, and unpack block there, all in runtime, after the 
build time.
This is entirely possible, but, as I said, only if there is no need for 
human choices which are:

 1) polymorphic implementation choice
 2) deploy-time configuration
The process can be automated, but not as much as for WARs because WARs 
are much less capable than blocks.

Unpacked blocks:
Good question -- maybe in WEB-INF/blocks ?


I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc 
them into $temp/blocks, where $temp is temporary directory 
configured in web.xml. WEB-INF/blocks/ can also have blocks.xml to 
point out to blocks which are located outside of the blocks 
directory, for development needs.


that might be a solution, but would force us to consider blocks 
read-only because, otherwise, if a block writes something on its 
internal file system, that content is not guaranteed to be  persistent.


We can either provide block deploy directory which will not be 
dependent on container behavior (like we allow specifying work 
directory in web.xml), or provide block temp directory.
well, which is what we do with WEB-INF/blocks/, don't we?

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Vadim Gritsenko]

Stefano Mazzocchi wrote:

On Sunday, Sep 14, 2003, at 18:31 Europe/Rome, Vadim Gritsenko wrote:

if you wish to have proper names, that would be a comman line 
property away. This, for example, is useful for those projects that 
might wish to still distribute a complete war (forrest comes to 
mind) where the wiring.xml file is generated at build time.


So the answer will be then: those directories are generated during 
build time.


It is entirely possible to create a build process that creates the 
wiring.xml file without using the block deploying tool. I think cocoon 
apps like Forrest/Lenya might want to choose two types of 
distribution: a big war with all the blocks pre-expanded and the 
wiring.xml generated at build time and another one as blocks to be 
deployed on top of an existing cocoon.


But would it be possible to provide big war with blocks not-expanded in 
the predefined directory [1] and with no wiring.xml generated and have 
deployer work it's magic?

Once such war is deployed, blocks unpacked and wiring xml generated 
(possibly with human intervention as you mentioned below) by the 
deployer tool, you get to the point were you can just zip everything up 
again and have a big war with all the blocks pre-expanded and the 
wiring.xml generated.


The first distribution is for those who don't have a cocoon already 
installed, the second will be for those who do.

 Is there a way to drop in block into expanded war and have block 
deployer pick it up?


It could be possible, but only if there is no polymorphic behavior 
associated to the dependencies of that block. Otherwise, human 
intervention to choose which block implementation would implement the 
required block behavior cannot be avoided.

Deployer will have to then pick up block from some directory, 
generate 123456789 directory, and unpack block there, all in runtime, 
after the build time.


This is entirely possible, but, as I said, only if there is no need 
for human choices which are:

 1) polymorphic implementation choice
 2) deploy-time configuration
The process can be automated, but not as much as for WARs because WARs 
are much less capable than blocks.

Unpacked blocks:
Good question -- maybe in WEB-INF/blocks ?


I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc 
them into $temp/blocks, where $temp is temporary directory 
configured in web.xml. WEB-INF/blocks/ can also have blocks.xml to 
point out to blocks which are located outside of the blocks 
directory, for development needs.


that might be a solution, but would force us to consider blocks 
read-only because, otherwise, if a block writes something on its 
internal file system, that content is not guaranteed to be  
persistent.


We can either provide block deploy directory which will not be 
dependent on container behavior (like we allow specifying work 
directory in web.xml), or provide block temp directory.


well, which is what we do with WEB-INF/blocks/, don't we?


Which brings us to square one: what will then be the directory (marked 
with [1]) for the not-expanded blocks? Is it the same directory or is it 
different directory?

Vadim

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Sunday, Sep 14, 2003, at 20:51 Europe/Rome, Vadim Gritsenko wrote:

Stefano Mazzocchi wrote:

On Sunday, Sep 14, 2003, at 18:31 Europe/Rome, Vadim Gritsenko wrote:

if you wish to have proper names, that would be a comman line 
property away. This, for example, is useful for those projects that 
might wish to still distribute a complete war (forrest comes to 
mind) where the wiring.xml file is generated at build time.


So the answer will be then: those directories are generated during 
build time.


It is entirely possible to create a build process that creates the 
wiring.xml file without using the block deploying tool. I think 
cocoon apps like Forrest/Lenya might want to choose two types of 
distribution: a big war with all the blocks pre-expanded and the 
wiring.xml generated at build time and another one as blocks to be 
deployed on top of an existing cocoon.


But would it be possible to provide big war with blocks not-expanded 
in the predefined directory [1] and with no wiring.xml generated and 
have deployer work it's magic?
why? isn't it easier to provide a wiring.xml already built?

Once such war is deployed, blocks unpacked and wiring xml generated 
(possibly with human intervention as you mentioned below) by the 
deployer tool, you get to the point were you can just zip everything 
up again and have a big war with all the blocks pre-expanded and the 
wiring.xml generated.
the deployer tool is not something that is run when the war is expanded 
and is *NOT* something that cocoon should have access to (at least, in 
its default CLI incarnation) [mainly for security reasons]

We can either provide block deploy directory which will not be 
dependent on container behavior (like we allow specifying work 
directory in web.xml), or provide block temp directory.


well, which is what we do with WEB-INF/blocks/, don't we?


Which brings us to square one: what will then be the directory (marked 
with [1]) for the not-expanded blocks? Is it the same directory or is 
it different directory?
My point is: there is no need for non-expanded blocks to be held on 
disk.

BTW, I have the impression I'm not understanding what you are aiming 
at. Instead of discussing the solution, can you point out the problems 
you see first? I think that would help me understand because at the 
moment, I'm not sure I do.

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Vadim Gritsenko]

Stefano Mazzocchi wrote:

My point is: there is no need for non-expanded blocks to be held on disk.

BTW, I have the impression I'm not understanding what you are aiming 
at. Instead of discussing the solution, can you point out the problems 
you see first? I think that would help me understand because at the 
moment, I'm not sure I do.


I'm not aiming at anything, just trying to understand/discuss... May be 
I just should wait for your introduction at gettogether :)

Vadim

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Friday, Aug 29, 2003, at 18:27 Europe/Rome, Vadim Gritsenko wrote:

Temp dir:
I've been assuming this file and dir structure is the persistent 
state for the block manager.


The only servlet engine which wipes out deployment (aka temp, aka 
staging) directory on restart is Jetty. None of the others known to me 
do this.
yes, but the spec says that temp is not guaranteed to stay. I don't 
want to base such a key functionality on something that is not rock 
solid and temp directories for servlet contexts are designed not to be.



If it has deployed the blocks, it records its state in this 
structure.  At Cocoon restart, this structure (wiring.xml and 
resulting filesystem tree) is used to initialize the 
blocks/components/etc. Otherwise the block deployer has to re-deploy 
everything on restart.  Have I got that right?


Remember, Cocoon is deployed here as a webapp.
Remember: when cocoon has blocks, you would *not* need to use a war in 
your life anymore for cocoon, only for the naked-cocoon.war file. the 
rest (even cluster replication) will be handled by the block deployer 
tool. [at least, that's my dream]

And webapp can be archived into the war file. Now the question: how 
funny (e.g. 384938958499) directories get into the war file in the 
first place?
yes, they would appear funny, but keep in mind that those names are 
given by the block deployer. if you wish to have proper names, that 
would be a comman line property away. This, for example, is useful for 
those projects that might wish to still distribute a complete war 
(forrest comes to mind) where the wiring.xml file is generated at build 
time.

Unpacked blocks:
Good question -- maybe in WEB-INF/blocks ?
I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc 
them into $temp/blocks, where $temp is temporary directory configured 
in web.xml. WEB-INF/blocks/ can also have blocks.xml to point out to 
blocks which are located outside of the blocks directory, for 
development needs.
that might be a solution, but would force us to consider blocks 
read-only because, otherwise, if a block writes something on its 
internal file system, that content is not guaranteed to be persistent.

I agree that you shouldn't store content in your block file system, 
but, hey, the servlet API tried to enforce that with leaving up to the 
containers to unpack wars and failed (even weblogic had to surrender to 
war unpacking for that IO problem).

In theory, it's all nice and good to keep things separate. In practice 
(and I speak out of linotype) having a file system under your feet is a 
great RAD ability and I wouldn't want to see it going away).

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Monday, Sep 1, 2003, at 16:59 Europe/Rome, Hunsberger, Peter wrote:

Geoff Howard [EMAIL PROTECTED] writes:

snip/

But this brings up another point - what to do if the wiring.xml and
others is deleted?  Presumably, all blocks are uninstalled in this
state, but what does this do to persistence requirements.
Also, how to recreate the deploy step efficiently?  For example:

You deploy a block with some dependencies and configuration.
The block
deploy process walks you through setting configs and resolving
dependencies.  You then have no record of these deployment choices
except in wiring.xml which is not meant for human
consumption.  Perhaps
it would be good to record these human-step deployment time
configurations in a conf file which could be easily reprocessed to
easily re-deploy all blocks to their last configuration.
The more I  watch this discussion go by the more I feel like Cocoon is
reinventing JBoss.
you are noting convergence of applying the same patterns onto two 
different domains. all operating systems have a file system, but this 
doesn't make them all the same thing.

The more I watch the Aspects discussion go by the
more I feel like Cocoon is reinventing JBoss.
same convergence again. all server side environments have crosscutting 
concerns, that will require similar solutions.

Too bad JBoss isn't a
container that we can just pick up for Cocoon and count on
I would be very glad to use something that already exists rather than 
reinventing the wheel. but I really see no way on making cocoon work on 
top of jboss and apply its modularization facility to polymorphic block 
deployment and its AOP framework on allow our continuation-based 
flowscript to be interceptable.

if you have any idea on how to do this, I'm all ears. even if the point 
is academic since we can't ship jboss with cocoon.

BTW, On the same issue more or less: I don't think you ever responded 
to
my question on what to do for a container for EJB samples supplied with
Cocoon?  (Still trying to get permission to contribute our code.)
we can't ship jboss since it's LGPLed. this is not going to change in 
the future.

we can wait for Geronimo to get real.

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Wednesday, Sep 10, 2003, at 13:39 Europe/Rome, Geoff Howard wrote:

Bruno Dumon wrote:
On Tue, 2003-09-09 at 17:02, Geoff Howard wrote:
...

I also considered recording the wire-id instead of the uri for  
connections between blocks - what are the arguments for each?

connection was out of the blue using the wiring metaphore.   
Other options?  Free association: connect, attach, solder, wire,  
use ...
Avalon Phoenix uses the words assembly and provide instead of
wiring and connection, which I quite like (I mean the assembly 
provide).
I don't quite see where these terms would be used - can you explain  
a little more?  Maybe a proposed set of changes to the example  above?
Yep. I meant that the connection tag would become provide:
 provide
name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/ 
provide
I think of the provide verb as applying more the the block.xml  
configuration (which isn't yet on the table).
agreed. in fact, I was thinking of exposes, but provides is good  
too.

 The wiring.xml describes not what a block provides, but which  
services provided by other blocks plug in to its named dependencies.
yes, I still believe that wiring is a much better name for this.

 OTOH, I guess the block manager could be seen as providing the  
solution to the named dependency...
no, a block implements a behavior to provide a service and is  
connected to the requiring block by the wiring created by the  
user deploying the block thru the block manager.

the block provides, the block manager connects.

the collection of connections is called the block wiring.

Note: the above is terminology taken from the electronic metaphore of  
wiring and solding chips on a board, where a socket is the block  
behavior (the contract) and the chip that goes into the socket is the  
implementation.

Historical note: the above was the reasoning from where got the very  
first ideas for Avalon. [Federico and I were working on something we  
called JLab, which should have been a mix between JavaStudio and  
LabView, but we never went anywhere (not surprising since our  
once-demo-scene-related-group is called Beta Version Productions and  
we never finish anything we start ;-)

[but software is never finished anyway, so what?]

And the wiring.xml would be called assembly.xml
OTOH, I'm meanwhile becoming accustomed to the wiring and connection
terms, so let's leave it as wiring and connection for now.
Ok, sounds good.
great

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Wednesday, Sep 10, 2003, at 13:47 Europe/Rome, Geoff Howard wrote:

Aha, I understand the issue now. And next to staging and live servers
there are of course also the development servers or workstations. So
there are parameters which will be common for all installations and
parameters which can be different, and it would indeed be useful if we
can feed those common parameters to the block deployer, so that only
system-dependent parameters need to be completed.
Hmm, now that I think of it, it would also be useful to feed the
system-dependent parameters to the block deployer, because I don't 
want
to re-enter those either when I do a clean block deploy.
Basically what I'm arriving at is that the block deployer should be 
able
to run in an interaction-less mode by providing it with input files
giving it all the information.
Exactly.

Or then maybe it becomes more useful to write the wiring.xml by hand 
and
place a few @token@'s here and there which are replaced by an ant 
script
based on the values in a local.properties file.
Although the stated intention was that wiring.xml was not meant to be 
edited by hand (except by experts suppose).  So, wild thinking of 
options:

- ant filtering tokens as you propose
- good old xml xpath-based manipulation between servers (xsl or xpatch 
tool)
- option to deploy with variables/propertynames instead of literal 
values?  For instance, if for servername you can either provide a 
literal value or $property.name and have a .properties file which 
defines property.name=mydevserver.com.  That way, you manage only 
which properties file exists on each server?

Need to think more about this...
Yup, and there are probably a number of solutions which could work 
without modifying the wiring.xml structure at all so it could probably 
be revisited at implementation time.
it is possible to add a namespaced local attribute to the 
configurations in the wiring file so that if a staging and/or cluster 
replication action is required, the block deployer can ask for the 
parameters again when replication the block installation on another 
machine.

But I would suggest to start with a single machine setup and then 
increase the functionality with user requirements, we already have 
enough things to do.

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Sunday, Aug 31, 2003, at 15:04 Europe/Rome, Christian Haul wrote:

Stefano Mazzocchi wrote:
On Wednesday, Aug 27, 2003, at 11:35 Europe/Rome, Christian Haul 
wrote:
Which is the whole point of my mail. Don't use dependency ranges, use
metadata specifying capabilities and requirements for this.
I think you greatly underestimate the complexity of the approach you 
are proposing.
Last thing I want is to enter the ontology problem space.
There is absolutely no need to go the full way and I don't suggest to 
do it. A simple list of features that are matched 1:1 would be orders 
of magnitude more powerful than version numbers.

But in case I'm missing your point, please provide an explicit 
example.
Actually, I have already provided one:

provides-features
   feature name=html-skin/
   feature name=wml-skin/
/provides-features
dependencies
   block name=core uri=core
  feature name=html-serializer/
   /block
/dependencies
This would be a very simple block that has little requirements and 
provides few features.

Let's look e.g. at the databases block. For ease of use, let's assume 
that any tag appearing beneath provides-features is a name of a 
feature and let's assume that features may have sub-features:

provides-features
   esql
  stored-procedures/
  grouping/
  get-xml/
  get-clob/
  get-blob/
   /esql
   sql-transformer
  stored-procedures/
  get-xml/
  get-clob/
  get-blob/
   /sql-transformer
   db-actions
  add/
  update/
  delete/
   /db-actions
   mod-actions
  add
 autoincrement
oracle/
informix/
mysql/
postgres/
hsqldb/
 /autoincrement
  /add
  update/
  delete/
  query/
   /mod-actions
/provides-features
Now, another block might require the following:

dependencies
   block name=databases uri=db
   !-- *this* block will refer to the block satisfying
the requirements as cob:db --
  esql
 grouping/
  /esql
  sql-transformer/
   /block
/dependencies
Which is apparently compatible. Even without knowing the semantics of 
a feature esql hence without ontologies.

OK, this is more expensive than comparing to integers. OTOH this will 
occurr only once when a new block is registered.
I am afraid of going down this path because you are not taking into 
account:

 1) semantic collision
 2) increased development/maintenance complexity due to more granular 
dependendies

even providing a fully namespaced taxonomy, the amount of topics 
would grow rather quickly and would also get into the keydata 
syndrome: what is a keydata for me might not be for you.

so, in order to depend on a block, you would not only need a 
dictionary, but a full thesaurus.

which, at the end, will end up being an ontology.

and this path scares me already too much to be willing to get into it.

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Stefano Mazzocchi wrote:
On Friday, Aug 29, 2003, at 05:53 Europe/Rome, Geoff Howard wrote:

Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring

For sake of discussion, I recorded a wire-id instead of the location.  
Can blocks be in other locations other than WEB-INF/blocks/{$wire-id}  ?
potentially, yes. Sylvain suggested that, during block development, you  
might want to keep the block in the directory you are used to and have  
cocoon point to that, instead of having to copy it there everytime.

so, you need to add a block/@location attribute (preferred over an  
element, because a block can have one and only one location)
Ok, I've udated the wiki to use @location (as proposed above, not as 
written below with location

...

blocks xmlns=http://apache.org/cocoon/blocks/wiring/1.0;

 block id=cob:mycompany.com/webmail/1.3.43
  locationWEB-INF/blocks/384938958499/location
  mount/mail//mount
  connections
   connection  
name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/ 
connection
   connection  
name=internal-skincob:mycompany.com/skins/corporate/34.3.345/ 
connection
   connection  
name=repositorycob:mycompany.com/repositories/email/exchange/3.2.1/ 
connection
  /connections
  configurations
   param name=userguest/param
   param name=passwordsj3u493/param
  /configurations
 /block

 block id=cob:mycompany.com/repositories/email/exchange/3.2.1
  locationWEB-INF/blocks/394781274834/location
  configurations
   param name=hostmail.blah.org/param
  /configuration
 /block
 block id=cob:yetanothercompany.com/skins/fancy/1.2.2
  locationWEB-INF/blocks/947384127832/location
 /block
 block id=cob:mycompany.com/skins/corporate/34.3.345
  locationWEB-INF/blocks/746394782637/location
 /block
/blocks

Rationale for this:

 1) there could be many blocks
 2) there can be only one block with the give URI in the system (so the  
use of '@id' is meaningful also from an XML perspective)
Ok, changed name to @id.

 3) the wire-id number is not semantically meaningful from a block  
perspective, it's simply autogenerated by the deployment tool, but  
location can be arbitrary and block URI are already uniquely  
idenfitying the block
Gotcha.  wire-id is gone.

 4) changed configuration in configurations to identify a container  
that can contain one or more parameters.
I took the liberty of changing this from configurations to parameters 
since in my mind configuration already refers to a group of settings but 
we want to keep the plural explicit.  Also, parameter better indicates 
the key-value expectation whereas configuration(s) may imply the 
possibility of deeper nested items.

connection was out of the blue using the wiring metaphore.  Other  
options?  Free association: connect, attach, solder, wire, use ...
I have no problems with this.

Is it wise to limit configurations to name-value pairs, or should 
that  allow arbitrary foreign xml markup?
No, name-value pairs is fine. Everything else would be too hard to  
configure at runtime and block shouldn't need too many parameters for  
configuration at deployment time.

For configuration, should a distinction be made between any  
create-time values and deploy-time values, or is that pointless once  
the wiring has happened?
that section will only contain deploy-time values. create-time values  
will be included in the block.xconf, which is the block equivalent of  
cocoon.xconf (and will be full xml configurations)
Ok, gotcha.

For the wiring connections: should the matching uri even be recorded  
here, or only the role its looking for? (I think the uri, but just  
tossing out questions).
yes, both name and URI are required to fully identify the wiring.

What blocks version is this?  1.0? 1.1? 2.1? 2.2?
Following namespace URI versioning conventions, I would say 1.0 since  
it's the first release of such a schema.
Wiki updated to reflect the current state.  I'll start on cob.xml if no 
one beats me to it.

Geoff

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Saturday, Sep 13, 2003, at 21:06 Europe/Rome, Geoff Howard wrote:

 4) changed configuration in configurations to identify a 
container  that can contain one or more parameters.
I took the liberty of changing this from configurations to parameters 
since in my mind configuration already refers to a group of settings 
but we want to keep the plural explicit.  Also, parameter better 
indicates the key-value expectation whereas configuration(s) may imply 
the possibility of deeper nested items.
+1

For the wiring connections: should the matching uri even be recorded 
 here, or only the role its looking for? (I think the uri, but just  
tossing out questions).
yes, both name and URI are required to fully identify the wiring.
What blocks version is this?  1.0? 1.1? 2.1? 2.2?
Following namespace URI versioning conventions, I would say 1.0 
since  it's the first release of such a schema.
Wiki updated to reflect the current state.  I'll start on cob.xml if 
no one beats me to it.
Go ahead, I'll chime in later.

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Bruno Dumon]

On Tue, 2003-09-09 at 17:02, Geoff Howard wrote:
 Bruno Dumon wrote:
  (catching up on block discussions...)
  
  On Fri, 2003-08-29 at 05:53, Geoff Howard wrote:
  snip/
  
 Implementation Phases
 -
 
 Phase 1: definition of the contract between the block manager inside 
 cocoon and the standalone block deployer. These contracts include:
 
  1) description of the file system layout (see above for a suggestion)
  2) description of the wiring document schema
  3) description of the block metadata schema
 
 Ok, the file system seems fine - how about starting the discussion with 
 the following for the wiring document?  (I'm assuming stuff will have to 
 change - just trying to get the ball rolling)
 
 ?xml version=1.0 encoding=UTF-8?
 blocks version=1.0
block uri=cob:mycompany.com/webmail/1.3.43 wire-id=384938958499
  mount/mail//mount
  connections
connection
 name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/connection
connection 
 name=internal-skincob:mycompany.com/skins/corporate/34.3.345/connection
connection 
 name=repositorycob:mycompany.com/repositories/email/exchange/3.2.1/connection
  /connections
  configuration
param name=userguest/param
param name=passwordsj3u493/param
  /configuration
/block
block uri=cob:mycompany.com/repositories/email/exchange/3.2.1 
 wire-id=394781274834
  configuration
param name=hostmail.blah.org/param
  /configuration
/block
block uri=cob:yetanothercompany.com/skins/fancy/1.2.2 
 wire-id=947384127832/
block uri=cob:mycompany.com/skins/corporate/34.3.345 
 wire-id=746394782637/
 /blocks
 
 Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring
 
 For sake of discussion, I recorded a wire-id instead of the location. 
 Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} ?
 
 I also considered recording the wire-id instead of the uri for 
 connections between blocks - what are the arguments for each?
 
 connection was out of the blue using the wiring metaphore.  Other 
 options?  Free association: connect, attach, solder, wire, use ...
  
  Avalon Phoenix uses the words assembly and provide instead of
  wiring and connection, which I quite like (I mean the assembly 
  provide).
 
 I don't quite see where these terms would be used - can you explain a 
 little more?  Maybe a proposed set of changes to the example above?
 

Yep. I meant that the connection tag would become provide:
 provide
name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/provide

And the wiring.xml would be called assembly.xml

OTOH, I'm meanwhile becoming accustomed to the wiring and connection
terms, so let's leave it as wiring and connection for now.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [RT] Implementing Cocoon Blocks

[Bruno Dumon]

On Tue, 2003-09-09 at 17:14, Geoff Howard wrote:
 Bruno Dumon wrote:
  On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:
  snip/
  
 But this brings up another point - what to do if the wiring.xml and 
 others is deleted?  Presumably, all blocks are uninstalled in this 
 state, but what does this do to persistence requirements.
 
 Also, how to recreate the deploy step efficiently?  For example:
 
 You deploy a block with some dependencies and configuration.  The block 
 deploy process walks you through setting configs and resolving 
 dependencies.  You then have no record of these deployment choices 
 except in wiring.xml which is not meant for human consumption.  Perhaps 
 it would be good to record these human-step deployment time 
 configurations in a conf file which could be easily reprocessed to 
 easily re-deploy all blocks to their last configuration.
  
  
  I think the conf file you're speaking of here is simply the wiring.xml
  file itself? Remember, the block deployer has read-write access to this
  file, so it can first read the existing information, then let the
  administrator modify it, and then write it back. It's not like each time
  you want to modify the configuration of one block you'll have to
  re-enter all the parameters for other blocks as well.
 
 Ugh, I see now that I didn't explain well the scenario I was thinking of 
 and now can't remember!  IIRC I was trying to think through the process 
 of replication and/or staging.  In this case, would I copy over 
 wiring.xml and all blocks directories? (presumably)  But, what if some 
 of the deploy-time configurations need to change on the way?  For 
 instance, on a staging server, you use a different database.  So, I was 
 just trying to get a picture in my head of how that would work and what 
 the pitfalls were.

Aha, I understand the issue now. And next to staging and live servers
there are of course also the development servers or workstations. So
there are parameters which will be common for all installations and
parameters which can be different, and it would indeed be useful if we
can feed those common parameters to the block deployer, so that only
system-dependent parameters need to be completed.

Hmm, now that I think of it, it would also be useful to feed the
system-dependent parameters to the block deployer, because I don't want
to re-enter those either when I do a clean block deploy.

Basically what I'm arriving at is that the block deployer should be able
to run in an interaction-less mode by providing it with input files
giving it all the information.

Or then maybe it becomes more useful to write the wiring.xml by hand and
place a few @token@'s here and there which are replaced by an ant script
based on the values in a local.properties file.

Need to think more about this...

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Bruno Dumon wrote:
On Tue, 2003-09-09 at 17:02, Geoff Howard wrote:
...

I also considered recording the wire-id instead of the uri for 
connections between blocks - what are the arguments for each?

connection was out of the blue using the wiring metaphore.  Other 
options?  Free association: connect, attach, solder, wire, use ...
Avalon Phoenix uses the words assembly and provide instead of
wiring and connection, which I quite like (I mean the assembly 
provide).
I don't quite see where these terms would be used - can you explain a 
little more?  Maybe a proposed set of changes to the example above?
Yep. I meant that the connection tag would become provide:
 provide
name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/provide
I think of the provide verb as applying more the the block.xml 
configuration (which isn't yet on the table).  The wiring.xml describes 
not what a block provides, but which services provided by other blocks 
plug in to its named dependencies.  OTOH, I guess the block manager 
could be seen as providing the solution to the named dependency...

And the wiring.xml would be called assembly.xml

OTOH, I'm meanwhile becoming accustomed to the wiring and connection
terms, so let's leave it as wiring and connection for now.
Ok, sounds good.

Geoff

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Bruno Dumon wrote:
On Tue, 2003-09-09 at 17:14, Geoff Howard wrote:

Bruno Dumon wrote:

On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:
snip/
But this brings up another point - what to do if the wiring.xml and 
others is deleted?  Presumably, all blocks are uninstalled in this 
state, but what does this do to persistence requirements.

Also, how to recreate the deploy step efficiently?  For example:

You deploy a block with some dependencies and configuration.  The block 
deploy process walks you through setting configs and resolving 
dependencies.  You then have no record of these deployment choices 
except in wiring.xml which is not meant for human consumption.  Perhaps 
it would be good to record these human-step deployment time 
configurations in a conf file which could be easily reprocessed to 
easily re-deploy all blocks to their last configuration.


I think the conf file you're speaking of here is simply the wiring.xml
file itself? Remember, the block deployer has read-write access to this
file, so it can first read the existing information, then let the
administrator modify it, and then write it back. It's not like each time
you want to modify the configuration of one block you'll have to
re-enter all the parameters for other blocks as well.
Ugh, I see now that I didn't explain well the scenario I was thinking of 
and now can't remember!  IIRC I was trying to think through the process 
of replication and/or staging.  In this case, would I copy over 
wiring.xml and all blocks directories? (presumably)  But, what if some 
of the deploy-time configurations need to change on the way?  For 
instance, on a staging server, you use a different database.  So, I was 
just trying to get a picture in my head of how that would work and what 
the pitfalls were.


Aha, I understand the issue now. And next to staging and live servers
there are of course also the development servers or workstations. So
there are parameters which will be common for all installations and
parameters which can be different, and it would indeed be useful if we
can feed those common parameters to the block deployer, so that only
system-dependent parameters need to be completed.
Hmm, now that I think of it, it would also be useful to feed the
system-dependent parameters to the block deployer, because I don't want
to re-enter those either when I do a clean block deploy.
Basically what I'm arriving at is that the block deployer should be able
to run in an interaction-less mode by providing it with input files
giving it all the information.
Exactly.

Or then maybe it becomes more useful to write the wiring.xml by hand and
place a few @token@'s here and there which are replaced by an ant script
based on the values in a local.properties file.
Although the stated intention was that wiring.xml was not meant to be 
edited by hand (except by experts suppose).  So, wild thinking of 
options:

- ant filtering tokens as you propose
- good old xml xpath-based manipulation between servers (xsl or xpatch tool)
- option to deploy with variables/propertynames instead of literal 
values?  For instance, if for servername you can either provide a 
literal value or $property.name and have a .properties file which 
defines property.name=mydevserver.com.  That way, you manage only which 
properties file exists on each server?

Need to think more about this...
Yup, and there are probably a number of solutions which could work 
without modifying the wiring.xml structure at all so it could probably 
be revisited at implementation time.

Geoff

Re: [RT] Implementing Cocoon Blocks

[Bruno Dumon]

(catching up on block discussions...)

On Fri, 2003-08-29 at 05:53, Geoff Howard wrote:
snip/
  Implementation Phases
  -
  
  Phase 1: definition of the contract between the block manager inside 
  cocoon and the standalone block deployer. These contracts include:
  
   1) description of the file system layout (see above for a suggestion)
   2) description of the wiring document schema
   3) description of the block metadata schema
 
 Ok, the file system seems fine - how about starting the discussion with 
 the following for the wiring document?  (I'm assuming stuff will have to 
 change - just trying to get the ball rolling)
 
 ?xml version=1.0 encoding=UTF-8?
 blocks version=1.0
block uri=cob:mycompany.com/webmail/1.3.43 wire-id=384938958499
  mount/mail//mount
  connections
connection
 name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/connection
connection 
 name=internal-skincob:mycompany.com/skins/corporate/34.3.345/connection
connection 
 name=repositorycob:mycompany.com/repositories/email/exchange/3.2.1/connection
  /connections
  configuration
param name=userguest/param
param name=passwordsj3u493/param
  /configuration
/block
block uri=cob:mycompany.com/repositories/email/exchange/3.2.1 
 wire-id=394781274834
  configuration
param name=hostmail.blah.org/param
  /configuration
/block
block uri=cob:yetanothercompany.com/skins/fancy/1.2.2 
 wire-id=947384127832/
block uri=cob:mycompany.com/skins/corporate/34.3.345 
 wire-id=746394782637/
 /blocks
 
 Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring
 
 For sake of discussion, I recorded a wire-id instead of the location. 
 Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} ?
 
 I also considered recording the wire-id instead of the uri for 
 connections between blocks - what are the arguments for each?
 
 connection was out of the blue using the wiring metaphore.  Other 
 options?  Free association: connect, attach, solder, wire, use ...

Avalon Phoenix uses the words assembly and provide instead of
wiring and connection, which I quite like (I mean the assembly 
provide).

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [RT] Implementing Cocoon Blocks

[Bruno Dumon]

On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:
snip/
 But this brings up another point - what to do if the wiring.xml and 
 others is deleted?  Presumably, all blocks are uninstalled in this 
 state, but what does this do to persistence requirements.
 
 Also, how to recreate the deploy step efficiently?  For example:
 
 You deploy a block with some dependencies and configuration.  The block 
 deploy process walks you through setting configs and resolving 
 dependencies.  You then have no record of these deployment choices 
 except in wiring.xml which is not meant for human consumption.  Perhaps 
 it would be good to record these human-step deployment time 
 configurations in a conf file which could be easily reprocessed to 
 easily re-deploy all blocks to their last configuration.

I think the conf file you're speaking of here is simply the wiring.xml
file itself? Remember, the block deployer has read-write access to this
file, so it can first read the existing information, then let the
administrator modify it, and then write it back. It's not like each time
you want to modify the configuration of one block you'll have to
re-enter all the parameters for other blocks as well.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Bruno Dumon wrote:
(catching up on block discussions...)

On Fri, 2003-08-29 at 05:53, Geoff Howard wrote:
snip/
Implementation Phases
-
Phase 1: definition of the contract between the block manager inside 
cocoon and the standalone block deployer. These contracts include:

1) description of the file system layout (see above for a suggestion)
2) description of the wiring document schema
3) description of the block metadata schema
Ok, the file system seems fine - how about starting the discussion with 
the following for the wiring document?  (I'm assuming stuff will have to 
change - just trying to get the ball rolling)

?xml version=1.0 encoding=UTF-8?
blocks version=1.0
  block uri=cob:mycompany.com/webmail/1.3.43 wire-id=384938958499
mount/mail//mount
connections
  connection
name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/connection
  connection 
name=internal-skincob:mycompany.com/skins/corporate/34.3.345/connection
  connection 
name=repositorycob:mycompany.com/repositories/email/exchange/3.2.1/connection
/connections
configuration
  param name=userguest/param
  param name=passwordsj3u493/param
/configuration
  /block
  block uri=cob:mycompany.com/repositories/email/exchange/3.2.1 
wire-id=394781274834
configuration
  param name=hostmail.blah.org/param
/configuration
  /block
  block uri=cob:yetanothercompany.com/skins/fancy/1.2.2 
wire-id=947384127832/
  block uri=cob:mycompany.com/skins/corporate/34.3.345 
wire-id=746394782637/
/blocks

Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring

For sake of discussion, I recorded a wire-id instead of the location. 
Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} ?

I also considered recording the wire-id instead of the uri for 
connections between blocks - what are the arguments for each?

connection was out of the blue using the wiring metaphore.  Other 
options?  Free association: connect, attach, solder, wire, use ...
Avalon Phoenix uses the words assembly and provide instead of
wiring and connection, which I quite like (I mean the assembly 
provide).
I don't quite see where these terms would be used - can you explain a 
little more?  Maybe a proposed set of changes to the example above?

Geoff

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Bruno Dumon wrote:
On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:
snip/
But this brings up another point - what to do if the wiring.xml and 
others is deleted?  Presumably, all blocks are uninstalled in this 
state, but what does this do to persistence requirements.

Also, how to recreate the deploy step efficiently?  For example:

You deploy a block with some dependencies and configuration.  The block 
deploy process walks you through setting configs and resolving 
dependencies.  You then have no record of these deployment choices 
except in wiring.xml which is not meant for human consumption.  Perhaps 
it would be good to record these human-step deployment time 
configurations in a conf file which could be easily reprocessed to 
easily re-deploy all blocks to their last configuration.


I think the conf file you're speaking of here is simply the wiring.xml
file itself? Remember, the block deployer has read-write access to this
file, so it can first read the existing information, then let the
administrator modify it, and then write it back. It's not like each time
you want to modify the configuration of one block you'll have to
re-enter all the parameters for other blocks as well.
Ugh, I see now that I didn't explain well the scenario I was thinking of 
and now can't remember!  IIRC I was trying to think through the process 
of replication and/or staging.  In this case, would I copy over 
wiring.xml and all blocks directories? (presumably)  But, what if some 
of the deploy-time configurations need to change on the way?  For 
instance, on a staging server, you use a different database.  So, I was 
just trying to get a picture in my head of how that would work and what 
the pitfalls were.

Geoff

Re: [RT] Implementing Cocoon Blocks

[Berin Loritsch]

Geoff Howard wrote:

Ryan Hoegg wrote:

This seems to be blurring the lines between the responsibilities of 
Cocoon and the container.  We might be able to reuse some ideas or 
even code that has been done in Merlin, Fortress, Loom, or Plexus for 
deployment time configuration and dependencies.


Anyone familiar with Fortress (which it seems we're going to as an 
intermediate until Merlin's full release) know if there's something 
which can help?  Berin?
Fortress introduces the concept of Extensions.  These Lifecycle Extensions
can introduce certain types of new features to the Cocoon world.  Between
that and the ComamandManager based stuff, I need some better info to give
you an idea of what can and can't be done in Fortress.
--

They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety.
- Benjamin Franklin

RE: [RT] Implementing Cocoon Blocks

[Hunsberger, Peter]

Geoff Howard [EMAIL PROTECTED] writes:

snip/

 But this brings up another point - what to do if the wiring.xml and 
 others is deleted?  Presumably, all blocks are uninstalled in this 
 state, but what does this do to persistence requirements.
 
 Also, how to recreate the deploy step efficiently?  For example:
 
 You deploy a block with some dependencies and configuration.  
 The block 
 deploy process walks you through setting configs and resolving 
 dependencies.  You then have no record of these deployment choices 
 except in wiring.xml which is not meant for human 
 consumption.  Perhaps 
 it would be good to record these human-step deployment time 
 configurations in a conf file which could be easily reprocessed to 
 easily re-deploy all blocks to their last configuration.

The more I  watch this discussion go by the more I feel like Cocoon is
reinventing JBoss. The more I watch the Aspects discussion go by the
more I feel like Cocoon is reinventing JBoss.  Too bad JBoss isn't a
container that we can just pick up for Cocoon and count on

BTW, On the same issue more or less: I don't think you ever responded to
my question on what to do for a container for EJB samples supplied with
Cocoon?  (Still trying to get permission to contribute our code.)

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Hunsberger, Peter wrote:

Geoff Howard [EMAIL PROTECTED] writes:

snip/

But this brings up another point - what to do if the wiring.xml and 
others is deleted?  Presumably, all blocks are uninstalled in this 
state, but what does this do to persistence requirements.

Also, how to recreate the deploy step efficiently?  For example:

You deploy a block with some dependencies and configuration.  
The block 
deploy process walks you through setting configs and resolving 
dependencies.  You then have no record of these deployment choices 
except in wiring.xml which is not meant for human 
consumption.  Perhaps 
it would be good to record these human-step deployment time 
configurations in a conf file which could be easily reprocessed to 
easily re-deploy all blocks to their last configuration.
The more I  watch this discussion go by the more I feel like Cocoon is
reinventing JBoss. The more I watch the Aspects discussion go by the
more I feel like Cocoon is reinventing JBoss.  Too bad JBoss isn't a
container that we can just pick up for Cocoon and count on
Maybe, but is there really anything (reusable) out there for such an 
amorphous thing as a block?  It's not (just) classloading or 
component/service location because some of the things a block can expose 
is a file or more generic behavior which will in some cases be very 
specific to Cocoon.  This assumption should of course be challenged - 
anyone see places we are unnecessarily reinventing the wheel?

BTW, On the same issue more or less: I don't think you ever responded to
my question on what to do for a container for EJB samples supplied with
Cocoon?  (Still trying to get permission to contribute our code.)
Sorry, must have missed that.  Can you remind me - were we talking about 
how to deal with the fact that an EJB example would rely on an EJB 
container which we don't provide?

Off the top of my head I'd say it's just like the SAP and other 
component(s) which rely on external dependencies we can't or don't ship. 
 If the examples can be provided in a container-neutral way, that's the 
best option of course.  Assuming that's not practical, I'd say start 
with what we have and over time perhaps we can accumulate 
container-specific versions.  If we have to tailor to one at the start, 
JBOSS is probably the best as it's at least available to everyone.

Am I on the right discussion?

Geoff

RE: [RT] Implementing Cocoon Blocks

[Hunsberger, Peter]

Geoff Howard [EMAIL PROTECTED] writes:

snip/

 Maybe, but is there really anything (reusable) out there for such an 
 amorphous thing as a block?  It's not (just) classloading or 
 component/service location because some of the things a block 
 can expose 
 is a file or more generic behavior which will in some cases be very 
 specific to Cocoon.  This assumption should of course be challenged - 
 anyone see places we are unnecessarily reinventing the wheel?

I don't think there is a complete set of solutions out there.  It's just
that things like automatic deployment, EAR/WAR/JAR expansion and
management, mechanisims for interpackage communications and aspect
interception are already part of JBoss.  It's a powerful set of
capabilities.  Also I suspect, but don't know for sure, that some of
what we want to do with blocks is probably easier if you have complete
interception capabilities, though perhaps that would mean turning the
concept of blocks inside out: inserting interceptions into code to gain
capabilities instead of looking up libraries to gain capabilities...

 
  BTW, On the same issue more or less: I don't think you ever 
 responded 
  to my question on what to do for a container for EJB 
 samples supplied 
  with Cocoon?  (Still trying to get permission to contribute 
 our code.)
 
 Sorry, must have missed that.  Can you remind me - were we 
 talking about 
 how to deal with the fact that an EJB example would rely on an EJB 
 container which we don't provide?
 
 Off the top of my head I'd say it's just like the SAP and other 
 component(s) which rely on external dependencies we can't or 
 don't ship. 
   If the examples can be provided in a container-neutral way, 
 that's the 
 best option of course.  Assuming that's not practical, I'd say start 
 with what we have and over time perhaps we can accumulate 
 container-specific versions.  If we have to tailor to one at 
 the start, 
 JBOSS is probably the best as it's at least available to everyone.
 
 Am I on the right discussion?

Yes.  I think what we'd provide initially would be JBoss compatible.  It
might run with other containers, but if so, that's only because we'd be
basic EJB 2.x compatible.

The problem with something like JBoss is that you can't simple add a
library to Cocoon and be done with it (like SAP).  Rather, you've got to
deploy Cocoon under JBoss, which, although somewhat simple, would likely
be best done with a new build target?  Something I'm not going to be
able to do at the moment...

RE: [RT] Implementing Cocoon Blocks

[Reinhard Poetz]

From: Hunsberger, Peter

 BTW, On the same issue more or less: I don't think you ever 
 responded to my question on what to do for a container for 
 EJB samples supplied with Cocoon?  (Still trying to get 
 permission to contribute our code.)

I would really like to see some EJB examples in Cocoon. IMO we should
create an ejb-samples block that contains them. Additionally we can
create a j2ee-container target for Ant that prepares everything (.ear
file) for deployment. We can't ship JBoss because of its license.

What do you think?

Reinhard

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Reinhard Poetz wrote:

From: Hunsberger, Peter


BTW, On the same issue more or less: I don't think you ever 
responded to my question on what to do for a container for 
EJB samples supplied with Cocoon?  (Still trying to get 
permission to contribute our code.)


I would really like to see some EJB examples in Cocoon. IMO we should
create an ejb-samples block that contains them. Additionally we can
create a j2ee-container target for Ant that prepares everything (.ear
file) for deployment. We can't ship JBoss because of its license.
What do you think?
Perfect.

Geoff

RE: [RT] Implementing Cocoon Blocks

[Hunsberger, Peter]

Reinhard Poetz [EMAIL PROTECTED] writes:
  
 From: Hunsberger, Peter
 
  BTW, On the same issue more or less: I don't think you ever
  responded to my question on what to do for a container for 
  EJB samples supplied with Cocoon?  (Still trying to get 
  permission to contribute our code.)
 
 I would really like to see some EJB examples in Cocoon. IMO 
 we should create an ejb-samples block that contains them. 
 Additionally we can create a j2ee-container target for Ant 
 that prepares everything (.ear
 file) for deployment. We can't ship JBoss because of its license.
 
 What do you think?

Yes, the Ant target seems the way to go.  I'm still trying to get
permission to make some of our code available.  Could take awhile...  In
the mean time, if someone wants to build the Ant support we might be
able to exploit it.  Or alternatively, perhaps the JAR/WAR/EAR prep we
do in  our build might be useful to someone? (I believe I've posted it
to the list in the past.)

Re: [RT] Implementing Cocoon Blocks

[Christian Haul]

Stefano Mazzocchi wrote:
On Wednesday, Aug 27, 2003, at 11:35 Europe/Rome, Christian Haul wrote:

Which is the whole point of my mail. Don't use dependency ranges, use
metadata specifying capabilities and requirements for this.
I think you greatly underestimate the complexity of the approach you are 
proposing.

Last thing I want is to enter the ontology problem space.
There is absolutely no need to go the full way and I don't suggest to do 
it. A simple list of features that are matched 1:1 would be orders of 
magnitude more powerful than version numbers.

But in case I'm missing your point, please provide an explicit example.
Actually, I have already provided one:

provides-features
   feature name=html-skin/
   feature name=wml-skin/
/provides-features
dependencies
   block name=core uri=core
  feature name=html-serializer/
   /block
/dependencies
This would be a very simple block that has little requirements and 
provides few features.

Let's look e.g. at the databases block. For ease of use, let's assume 
that any tag appearing beneath provides-features is a name of a 
feature and let's assume that features may have sub-features:

provides-features
   esql
  stored-procedures/
  grouping/
  get-xml/
  get-clob/
  get-blob/
   /esql
   sql-transformer
  stored-procedures/
  get-xml/
  get-clob/
  get-blob/
   /sql-transformer
   db-actions
  add/
  update/
  delete/
   /db-actions
   mod-actions
  add
 autoincrement
oracle/
informix/
mysql/
postgres/
hsqldb/
 /autoincrement
  /add
  update/
  delete/
  query/
   /mod-actions
/provides-features
Now, another block might require the following:

dependencies
   block name=databases uri=db
   !-- *this* block will refer to the block satisfying
the requirements as cob:db --
  esql
 grouping/
  /esql
  sql-transformer/
   /block
/dependencies
Which is apparently compatible. Even without knowing the semantics of a 
feature esql hence without ontologies.

OK, this is more expensive than comparing to integers. OTOH this will 
occurr only once when a new block is registered.

	Chris.

--
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Vadim Gritsenko wrote:
Geoff Howard wrote:

Vadim Gritsenko wrote:

Stefano Mazzocchi wrote:
...
Ok, great. Does anybody have a problem with the proposed file 
system  layout?
AFAIU, blocks are expanded into WEB-INF/blocks/\d+/ directories:
By default - but as I understood Stefano's last email, it should be 
possible to override?

the file system layout (relative to the cocoon webapp context) is

   [-] WEB-INF
L___ [-] blocks
  L___ [-] 384938958499
  | L___ [-] BLOCK-INF
  | | L___ block.xml
  | L_ (the contents of cob:mycompany.com/webmail/1.3.43)
Why temp directory is not used here? And, where unpacked blocks are 
stored?
earlier in the RT he said that the location is resolved relative to the 
webapp dir if relative location is given (WEB-INF/blocks/384938958499 ) 
but could also be absolute ($TOMCAT_HOME/work/blocks)

Temp dir:
I've been assuming this file and dir structure is the persistent state 
for the block manager.
The only servlet engine which wipes out deployment (aka temp, aka 
staging) directory on restart is Jetty. None of the others known to me 
do this.
Which is unfortunate since that's the one we ship for the demo.  So 
whatever we come up with has to work well for it too out of the box.

If it has deployed the blocks, it records its state in this 
structure.  At Cocoon restart, this structure (wiring.xml and 
resulting filesystem tree) is used to initialize the 
blocks/components/etc. Otherwise the block deployer has to re-deploy 
everything on restart.  Have I got that right?
Remember, Cocoon is deployed here as a webapp. And webapp can be 
archived into the war file. Now the question: how funny (e.g. 
384938958499) directories get into the war file in the first place?
Ah, I see your point now - unexploded wars is the issue.  Blocks can be 
wired before building a war, and after webapp deploy if the war is 
exploded, but if you prefer (or require) the war unexploded you wouldn't 
be able to deploy new blocks.

So, the WEB-INF/blocks (actually, the location of wiring.xml) must be 
configurable (which is what I think was proposed anyway) at the webapp 
level (web.xml?, cocoon.xconf?)  from there though, I assume its best to 
autogenerate some secret key for the actual location (as the \d+ above) 
to enforce that only the block deploy tool and the block manager know 
where to locate the actual resources on disk.  At least, that's what I 
assume the purpose of this point in the proposal was.  Stefano's off 
list - anyone know his reasoning on this?

But this brings up another point - what to do if the wiring.xml and 
others is deleted?  Presumably, all blocks are uninstalled in this 
state, but what does this do to persistence requirements.

Also, how to recreate the deploy step efficiently?  For example:

You deploy a block with some dependencies and configuration.  The block 
deploy process walks you through setting configs and resolving 
dependencies.  You then have no record of these deployment choices 
except in wiring.xml which is not meant for human consumption.  Perhaps 
it would be good to record these human-step deployment time 
configurations in a conf file which could be easily reprocessed to 
easily re-deploy all blocks to their last configuration.

Alternate versions of this file may be needed as blocks move from dev to 
staging to live, etc.

Unpacked blocks:
Good question -- maybe in WEB-INF/blocks ?
I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc them 
into $temp/blocks, where $temp is temporary directory configured in 
web.xml. WEB-INF/blocks/ can also have blocks.xml to point out to blocks 
which are located outside of the blocks directory, for development needs.
I think the unpacked blocks can be anywhere and don't even need to be 
kept around?  The deploy process (the wiring step) will probably have to 
require specifying the physical location of the cob file.  Or maybe this 
just needs to be a webapp level config (like the unpack/wire destination 
directory) to specify the block library locations.  Am I on the right 
track here?

Geoff

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard]

Getting the ball rolling on Phase One...

Stefano Mazzocchi wrote:
This is a collection of (more or less) random thoughts about the 
implementation of Cocoon Blocks that I collected while talking with 
Ricardo and Sylvain IRL.

Please note that anything proposed here, while organic and workable, is 
not to be considered carved in stone, but rather a suggestion on how to 
move forward.
...

File System Layout and wiring data
--
...

The deployment process added the mounting, wiring and configuration 
information

 cob:mycompany.com/webmail/1.3.43
  located at - WEB-INF/blocks/384938958499
  mounted on - /mail/
  external-skin - cob:yetanothercompany.com/skins/fancy/1.2.2
  internal-skin - cob:mycompany.com/skins/corporate/34.3.345
  repository - cob:mycompany.com/repositories/email/exchange/3.2.1
  configured as:
   user - guest
   password - sj3u493
 cob:mycompany.com/repositories/email/exchange/3.2.1
  located at - WEB-INF/blocks/394781274834
  configured as:
host - mail.blah.org
 cob:yetanothercompany.com/skins/fancy/1.2.2
  located at - WEB-INF/blocks/947384127832
 cob:mycompany.com/skins/corporate/34.3.345
  located at - WEB-INF/blocks/746394782637
the file system layout (relative to the cocoon webapp context) is

   [-] WEB-INF
L___ [-] blocks
  L___ wiring.xml
  L___ [-] 384938958499
  | L___ [-] BLOCK-INF
  | | L___ block.xml
  | L_ (the contents of cob:mycompany.com/webmail/1.3.43)
  L___ [-] 947384127832
  | L___ [-] BLOCK-INF
  | | L___ block.xml
  | L_ (the contents of 
cob:yetanothercompany.com/skins/fancy/1.2.2)
  L___ [-] 746394782637
  | L___ [-] BLOCK-INF
  | | L___ block.xml
  | L_ (the contents of 
cob:mycompany.com/skins/corporate/34.3.345)
  L___ [-] 394781274834
L___ [-] BLOCK-INF
| L___ block.xml
L_ (the contents of 
cob:mycompany.com/repositories/email/exchange/3.2.1

where

 wiring.xml contains the block IDs (which also identifies their location 
on disk) wiring, mounting and configurations.

 block.xml contains the block metadata (which belong to the block and 
cannot be changed at deployment time).

NOTE: if the location path of the block is relative, it is searched by 
starting from the cocoon war context. The block content is *always* 
extracted from the archives and saves as is inside the folder.

NOTE (development time): in order to simplify block creation and 
development, it will be possible to explicity indicate the location of 
an already existing and extracted block implementation on disk. The 
block manager should also have autoreloading features (configurable, of 
course) that should reload the configurations, the wiring and the 
exposed components when they are changed.
...

Implementation Phases
-
Phase 1: definition of the contract between the block manager inside 
cocoon and the standalone block deployer. These contracts include:

 1) description of the file system layout (see above for a suggestion)
 2) description of the wiring document schema
 3) description of the block metadata schema
Ok, the file system seems fine - how about starting the discussion with 
the following for the wiring document?  (I'm assuming stuff will have to 
change - just trying to get the ball rolling)

?xml version=1.0 encoding=UTF-8?
blocks version=1.0
  block uri=cob:mycompany.com/webmail/1.3.43 wire-id=384938958499
mount/mail//mount
connections
  connection
name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/connection
  connection 
name=internal-skincob:mycompany.com/skins/corporate/34.3.345/connection
  connection 
name=repositorycob:mycompany.com/repositories/email/exchange/3.2.1/connection
/connections
configuration
  param name=userguest/param
  param name=passwordsj3u493/param
/configuration
  /block
  block uri=cob:mycompany.com/repositories/email/exchange/3.2.1 
wire-id=394781274834
configuration
  param name=hostmail.blah.org/param
/configuration
  /block
  block uri=cob:yetanothercompany.com/skins/fancy/1.2.2 
wire-id=947384127832/
  block uri=cob:mycompany.com/skins/corporate/34.3.345 
wire-id=746394782637/
/blocks

Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring

For sake of discussion, I recorded a wire-id instead of the location. 
Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} ?

I also considered recording the wire-id instead of the uri for 
connections between blocks - what are the arguments for each?

connection was out of the blue using the wiring metaphore.  Other 
options?  Free association: connect, attach, solder, wire, use ...

Is it wise to limit configurations to name-value pairs, or should that 
allow arbitrary foreign xml markup?

For configuration, should a distinction be made between any 

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

On Wednesday, Aug 27, 2003, at 11:35 Europe/Rome, Christian Haul wrote:

Which is the whole point of my mail. Don't use dependency ranges, use
metadata specifying capabilities and requirements for this.
I think you greatly underestimate the complexity of the approach you 
are proposing.

Last thing I want is to enter the ontology problem space.

But in case I'm missing your point, please provide an explicit example.

--
Stefano.

Re: [RT] Implementing Cocoon Blocks

[Vadim Gritsenko]

Geoff Howard wrote:

Vadim Gritsenko wrote:

Stefano Mazzocchi wrote:
...
Ok, great. Does anybody have a problem with the proposed file 
system  layout?


AFAIU, blocks are expanded into WEB-INF/blocks/\d+/ directories:


By default - but as I understood Stefano's last email, it should be 
possible to override?

the file system layout (relative to the cocoon webapp context) is

   [-] WEB-INF
L___ [-] blocks
  L___ [-] 384938958499
  | L___ [-] BLOCK-INF
  | | L___ block.xml
  | L_ (the contents of cob:mycompany.com/webmail/1.3.43)


Why temp directory is not used here? And, where unpacked blocks are 
stored?


Temp dir:
I've been assuming this file and dir structure is the persistent state 
for the block manager.


The only servlet engine which wipes out deployment (aka temp, aka 
staging) directory on restart is Jetty. None of the others known to me 
do this.


If it has deployed the blocks, it records its state in this 
structure.  At Cocoon restart, this structure (wiring.xml and 
resulting filesystem tree) is used to initialize the 
blocks/components/etc. Otherwise the block deployer has to re-deploy 
everything on restart.  Have I got that right?


Remember, Cocoon is deployed here as a webapp. And webapp can be 
archived into the war file. Now the question: how funny (e.g. 
384938958499) directories get into the war file in the first place?


Unpacked blocks:
Good question -- maybe in WEB-INF/blocks ?


I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc them 
into $temp/blocks, where $temp is temporary directory configured in 
web.xml. WEB-INF/blocks/ can also have blocks.xml to point out to blocks 
which are located outside of the blocks directory, for development needs.

Vadim

Re: [RT] Implementing Cocoon Blocks

[Christian Haul]

On 26.Aug.2003 -- 06:33 PM, Stefano Mazzocchi wrote:
 
 On Monday, Aug 25, 2003, at 11:12 Europe/Rome, Christian Haul wrote:
 
 On 17.Aug.2003 -- 07:00 PM, Stefano Mazzocchi wrote:
 
 Issues that were still unsolved
 
 
 
 1) block identification
 
 All blocks (behaviors and implementations) are identified by a URI. 
 the
 format of the URI is as follows:
 
  cob:organization/name/x.y(.z)
 
 If we would identify a block by an XML document instead of a URI, we
 could list features of a block. Version numbers are a very poor tool
 to match requirements and capabilities.
 
 nonono, you are making the usual URL vs URI mistake: we want to 
 *identify* a block (either its implementation or its behavior). The 
 location service (that is also, metadata discovery about that block) is 
 an entirely separate issue and *MUST* remain the same in order to allow 
 a high level of decoupling between a resource and the actual location 
 of where those resources are.

IOW there is no need to force a naming scheme. So why should we?
Anyway, this was intended for the discussion of

  2) dependency ranges

and I'm glad that you see this problem solved by the discovery
service. However, I don't get why you need dependency ranges:

 When a block implementation depends on another block (either
 implementation or behavior), it should be able to have an 'elastic'
 dependency which doesn't connect it to the versioned identifier, but 
 to
 a range of those versions.

Which is the whole point of my mail. Don't use dependency ranges, use
metadata specifying capabilities and requirements for this.

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Re: [RT] Implementing Cocoon Blocks

[Bertrand Delacretaz]

Le Dimanche, 17 aoû 2003, à 19:00 Europe/Zurich, Stefano Mazzocchi a 
écrit :

lots-of-cool-stuff-snipped/

...This means that, in order to achieve, back compatibility, when a 
block is deployed on cocoon, the sitemap interpreter asks the block 
manager whether or not there is some mounted block that matches the 
incoming request, if so, that block is invoqued, otherwise, it falls 
back on the main sitemap.

This implies that it's entirely possible that a block obscures 
pipelines located in the mail cocoon sitemap (or subsitemaps mounted 
the direct way in there), but it is suggested that the sitemap 
interpreter doesn't fallback to the main sitemap if the block sitemap 
is invoqued, but no matching pipeline is located. This is to avoid 
potentially dangerous (security-wise) holes in the block URL-space 
covering that could lead to hard to forecast issues...
Sounds good but maybe making the block matching explicit in the 
sitemap would be clearer, something like map:match-blocks/ that can 
be placed at the same level than map:match to control when the block 
matching happens.

Use cases:
1) temporarily disable a block by matching its URL before 
map:match-blocks (for maintenance and testing purposes)

2) easily debug possible conflicts between blocks and non-blocks 
matchers, by moving match-blocks around.

3) completely disable blocks by not having map:match-blocks in the 
sitemap

Thoughts?

-Bertrand

Re: [RT] Implementing Cocoon Blocks

[Christian Haul]

On 17.Aug.2003 -- 07:00 PM, Stefano Mazzocchi wrote:
 
 Issues that were still unsolved
 
 
 
 1) block identification
 
 All blocks (behaviors and implementations) are identified by a URI. the 
 format of the URI is as follows:
 
  cob:organization/name/x.y(.z)

If we would identify a block by an XML document instead of a URI, we
could list features of a block. Version numbers are a very poor tool
to match requirements and capabilities. Then we could solve

  2) dependency ranges
 
 When a block implementation depends on another block (either 
 implementation or behavior), it should be able to have an 'elastic' 
 dependency which doesn't connect it to the versioned identifier, but to 
 a range of those versions.

by using another XML document that lists required features. This way
it would be easy to decide if two blocks a compatible.

Those two documents, let's call them requires.xml and provides.xml,
could reside in the meta data subtree of the archive. The requires.xml
would need to declare a URI for every block it depends on which is
used to refer to it.

Example
===
(This example is probably poor but should still illustrate the idea)


block really cool skin

provides-features
   feature name=html-skin/
   feature name=wml-skin/
/provides-features

dependencies
   block name=core uri=core
  feature name=html-serializer/
   /block
/dependencies

map:sitemap
 !-- ... --

  map:transform src=cob:core/html-skin/

 !-- ... --
map:sitemap

Now, the block manager would select the block with the highest version
number that provides all required features and would map the
cob:core prefix to that particular block.

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

[RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

This is a collection of (more or less) random thoughts about the 
implementation of Cocoon Blocks that I collected while talking with 
Ricardo and Sylvain IRL.

Please note that anything proposed here, while organic and workable, is 
not to be considered carved in stone, but rather a suggestion on how to 
move forward.

 - o -

Design Constraints
--
1) impact on back compatibility should be minimal, optimally none. that 
is: everything that worked before the introduction of blocks should 
continue to work with no required changes [this will reduce migration 
issues]

2) the implementation should be incremental and evolutionary. no 
radical changes in the cocoon architecture should be created [this will 
reduce the amount of code to write and also provide better regression]

3) the CVS tree should be buildable at all times [this will be enforced 
by an evolutionary approach to the implementation]

4) security of the architecture for block managing and deploying is a 
*TOP* priority and should be introduced up front.

5) deployment should be system administrator-friendly. that is, should 
*NOT* require GUIs or webapps (even if it should allow them to be 
possible)

 - o -

The overall architecture

Let's start with the first requirement: security.

Blocks are functional components at the webapp level. If a user is able 
to change the block wiring, the user is, potentially, able to execute 
his/her own code with the same security level of the entire cocoon 
application.

For this reason, the block wiring information should be located in a 
configuration file that is read-only by cocoon and read/write by 
the block deployer.

  ++  ++
  | cocoon | --- [File System] --- | block deployer |
  ++  ++
Note that the block deployer *could* be anything (a CLI, a webapp, an 
eclipse plugin). The above meets our second requirement: user 
friendlyness for all types of users.

Also note that it meets, potentially, the ability for the system 
administrators to perform actions such as 'staging' and 'cluster 
replication' by simply performing a file copy. Cocoon should be able to 
reload the block wiring information if this is changed.

In order to improve security and avoid DoS, there is *no way* for the 
block deployer to signal directly information to the cocoon instance 
(and no way for the cocoon instance to modify the wiring information or 
to communicate directly with the block deployer). Everything is 
performed thru the use of the file system.

The block deployer
--
The block deployer architecture is the following

  ++ +--+
  | +---+  | |  |
 [FS] | FS Driver |  | - |  User Interface  |
  | +---+  | |  |
  || +--+
  |  block |
  |services|
  ||
  |  +-+   |
  | +-+|   |
  | | Locator |+   |
  | +-+|
  +--^-+
 |
 V
block library
which is composed by four main parts:

 1) the file system driver: the part responsible for reading/writing 
the block wiring information and block configurations, to extract the 
files from the blocks distrubution archives and physically deploy the 
extracted files on the file system. There is no need for polymorphism 
for this part since there needs to be a solid file system contract 
between this driver and the cocoon block manager (included inside 
cocoon) which will need to read the block wiring info and locate the 
files on the file system.

 2) the block locator: the part responsible for locating the metadata 
associated with a given block identifier and thus, provide enough data 
for the block services and the user interface to drive the installation 
process. This part needs polymorphism. Potential implemenation of this 
locator are:

   a) file system-based locator: the block metadata and location 
information is stored in a file on disk.

   b) network service-based locator: the block metadata is provided 
by a network service (for example, a web service).

The block deployer can use multiple locators at the same time, in a 
cascading way: it should be possible to configure the block deployer 
with the kind of location services and provide a priority for which one 
to use. This allows, for example, to provide an architecture for block 
discovery that could work like this:

  block deployer --- company block library - cocoon official library

[a collection of blocks is called a block library. the application 
that, given a block identifier, looks up its metadata is called