You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/08/17 19:00:27 UTC
[RT] Implementing Cocoon Blocks
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 "block
librarian".]
3) the block services: the part that is shared by all potential block
deployers (no matter how the user inteface is implemented).
4) the user interface: the part that is driving the block services but
it's dependent on the user interface.
- o -
The Block Manager
-----------------
The block manager is the part that is responsible for handling the
block wiring information. This is included inside cocoon and it can
read and interpret the block wiring information written by the block
deployer.
The block manager is the only part of cocoon that knows how block are
wired together and where their actual location on disk is.
The block manager will be queried by all the cocoon internal services
that need to locate block-dependent stuff, that is:
1) the sitemap interpreter: to find out where the blocks sitemaps are
mounted in the main sitemap URL space
2) the block: protocol: to locate the services provided by the blocks
3) the component manager: to locate components provided by the blocks
(either avalon components, sitemap components and virtual components)
- o -
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: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
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"
the above information is extracted from the block metadata included
inside the blocks themselves and is deployment independent (also, the
deployment process cannot modify these properties)
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.
- o -
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)
where
cob: is a virtual protocol that is used instead of http:// to avoid
the problem of mistaking the URI for a URL
"organization" is the unique identifier for the organization that is
responsible for the maintenance of that identifier. the ICANN domain
name should be used [for example, apache.org for the ASF and so on]
"name" is the unique name of the identifier. it is suggested that a
path delimiter is used to further specialize the name (see belows for
examples)
x.y.z is the version identifier
x -> major (>= 1)
y -> minor (>= 0)
z -> bugfix (>= 0) (only for implementations)
NOTE: identifiers are case insensitive.
Example of good identifiers are
cob:apache.org/cocoon/PDF/2.6
cob:apache.org/cocoon/Fop/3.4.34
cob:apache.org/cocoon/iText/1.0.43
cob:mycompany.com/mydepartment/myself/myblock/3.2.23
example of bad identifiers
cob:cocoon.apache.org/whatever/2.3.434
the use of the virtual host instead of the domain name should be
avoided because it mixes location and identification concerns.
cob:apache.org/cocoon/block/whatever/2.3.4
the inclusion of the "block" name should be avoided because redundant
(the cob virtual protocol was introduced exactly to specify block
specificity and avoid location and identification semantic collisions)
cob:apache.org/cocoon/PDF/Fop/2.3.43
information of what behavior is implemented by a given block
implementation should not be included in the identifier.
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.
Instead of explicitly indicate the range description language, it is
suggested to implicity describe range rules. These implicit range rules
are:
a) if the dependency doesn't include the version, all versions are
matched
ex: both "cob:apache.org/blah/1.0" and "cob:apache.org/blah/3.43.342"
are matched by "cob:apache.org/blah"
b) if the dependency includes a version, versions are matched with the
following rules
i) if major is equal
ii) if minor is greater or equal
iii) in case of implementations and if minor is equal, if bugfix is
greater or equal
ex: depending on "cob:apache.org/blah/2.0.34" will match
- cob:apache.org/blah/2.0.345
- cob:apache.org/blah/2.3.23
but not
- cob:apache.org/blah/1.0.0
- cob:apache.org/blah/34.323.324534
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.
4) block mounting
Some blocks are meant to be publicly accessible and, for this reason,
they can be "mountable" onto a particular location of the URL space
handled by Cocoon.
Such mounting will be "implicit", meaning that the main cocoon sitemap
will not be modified by the block deployer.
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.
This means that the sitemap interpreter should:
check with the block manager if a block matches the request
if so, pass the request to the block that is mounted in that location
if not pipeline matches the request in that block, trigger a 404
if no block is mounted on that location, invoque the cocoon main
sitemap
5) block configuration at deployment time
blocks will contain configurations that is written at block-release
time but there are information that are deployment dependent. The block
deployment descriptor contains a list of those configurations that are
required to be entered at deployment time.
Since these configurations will rather be context-dependent tokens,
these can be considered more as properties. An example of a descriptor
could be:
<properties>
<property name="username">
<default>guest</default>
<description>The name of the user</description>
</property>
...
</properties>
then, these values will be accessible in the usual block.xconf using
{name} style. For example
...
<datasources>
<datasource name="rbdms">
<username>{username}</username>
...
</datasource>
</datasources>
...
- o -
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
Phase 2: definition and implementation of the block data model, with
reading/writing capabilities
1) implementation of the block wiring data model
2) implementation of the xml -> data model parser
3) implementation of the data model -> xml serializer
NOTE: since the xml formats are *not* meant to be human editable,
roundtripping of comments or formatting included in those xml files
should not be a priority.
At this point, implementation can work parallel:
Phase 3 - cocoon side: implementation of block support.
This phase includes:
3a) implementation of the BlockManager
3b) implementation of the block: protocol handler
3c) implementation of the link transformer
3d) implementation of the reload watchdog
[note: the link transformer has to be "block" aware in order to
identify where other blocks are mounted]
NOTE: during this phase, development can happen with a handwritten and
extracted block wiring info and block descriptors.
Phase 3 - deployer side: definition of the interfaces between the
components:
3a) the Locator interface
3b) the Block services interfaces
Phase 4 - deployer side: implementation of a basic block deployer
4a) implementation of the block services
4b) implementation of a "file system"-based locator
4c) implementation of a command-line user interface
Phase 5 - deployer side: implementation of a webservice block librarian
5a) implementation of a REST-style web service locator
5b) implementation of a cocoon block that implements block librarian
capabilities
- o -
Awaiting for your comments.
--
Stefano.
Re: [RT] Implementing Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [RT] Implementing Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [RT] Implementing Cocoon Blocks
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [RT] Implementing Cocoon Blocks
Posted by Geoff Howard <co...@leverageweb.com>.
Andreas Hochsteger wrote:
>
> Geoff Howard wrote:
>
> *snip many good suggestions from Geoff and Stefano*
>
>> 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?
>
> Where does the wire-id come from?
> Is it an ID which is dynamically created at deployment time or has that
> to be unique among all possible blocks on the net (would be hard to
> manage)?
This was mimicked (as was everything else) from Stefano's original
proposal, so I can't answer with authority... but I've assumed this was
autogenerated by the block-deploy mechanism (Block Manager). So, not
globally unique, just unique within a given wiring.xml and therefore a
given Cocoon instance.
>> <connection> was out of the blue using the wiring metaphore. Other
>> options? Free association: connect, attach, solder, wire, use ...
>
> Do the terms 'connection' and 'wire' represent the block dependencies?
> If so, why not just call them so?
> I think it's much easier to understand IMHO.
> Wiring is perceived as complicated at least in my mind although I've
> learned how to create electronic circiuts ;-)
Again, only my understanding:
No, this is the actual connections made between the dependencies
declared in the block's config declarations. There is another schema
for that which is yet to come which describes dependencies. The wiring
as I understand it is the _resolved_ dependencies which are figured out
by the block manager/deploy admin at deploy time.
What isn't yet represented but maybe should be is what happens if I
deploy a block for which some dependencies are met, but not all (yet).
How to represent that a block is in the system, but not yet active
because it is still waiting for a block to provide a missing dependency.
In my head I'm thinking that it will be possible to have interconnected
dependencies which have to go in place all at once. Can that
possibility be logically eliminated?
>> Is it wise to limit configurations to name-value pairs, or should that
>> allow arbitrary foreign xml markup?
>
> Arbitrary foreign XML markup might not be a mistake IMO.
Can anyone think of use cases?
Geoff
Re: [RT] Implementing Cocoon Blocks
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Geoff Howard wrote:
*snip many good suggestions from Geoff and Stefano*
> 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?
Where does the wire-id come from?
Is it an ID which is dynamically created at deployment time or has that
to be unique among all possible blocks on the net (would be hard to manage)?
> <connection> was out of the blue using the wiring metaphore. Other
> options? Free association: connect, attach, solder, wire, use ...
Do the terms 'connection' and 'wire' represent the block dependencies?
If so, why not just call them so?
I think it's much easier to understand IMHO.
Wiring is perceived as complicated at least in my mind although I've
learned how to create electronic circiuts ;-)
> Is it wise to limit configurations to name-value pairs, or should that
> allow arbitrary foreign xml markup?
Arbitrary foreign XML markup might not be a mistake IMO.
> 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?
>
> 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).
>
> What blocks version is this? 1.0? 1.1? 2.1? 2.2?
>
> Hack away,
> Geoff
Bye,
Andreas
Re: [RT] Implementing Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
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-skin">cob: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
Posted by Geoff Howard <co...@leverageweb.com>.
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-skin">cob: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
Posted by Bruno Dumon <br...@outerthought.org>.
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-skin">cob:yetanothercompany.com/skins/fancy/1.2.2</connection>
> >> <connection
> >>name="internal-skin">cob:mycompany.com/skins/corporate/34.3.345</connection>
> >> <connection
> >>name="repository">cob:mycompany.com/repositories/email/exchange/3.2.1</connection>
> >> </connections>
> >> <configuration>
> >> <param name="user">guest</param>
> >> <param name="password">sj3u493</param>
> >> </configuration>
> >> </block>
> >> <block uri="cob:mycompany.com/repositories/email/exchange/3.2.1"
> >>wire-id="394781274834">
> >> <configuration>
> >> <param name="host">mail.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-skin">cob: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
bruno@outerthought.org bruno@apache.org
Re: [RT] Implementing Cocoon Blocks
Posted by Geoff Howard <co...@leverageweb.com>.
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-skin">cob:yetanothercompany.com/skins/fancy/1.2.2</connection>
>> <connection
>>name="internal-skin">cob:mycompany.com/skins/corporate/34.3.345</connection>
>> <connection
>>name="repository">cob:mycompany.com/repositories/email/exchange/3.2.1</connection>
>> </connections>
>> <configuration>
>> <param name="user">guest</param>
>> <param name="password">sj3u493</param>
>> </configuration>
>> </block>
>> <block uri="cob:mycompany.com/repositories/email/exchange/3.2.1"
>>wire-id="394781274834">
>> <configuration>
>> <param name="host">mail.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
Posted by Bruno Dumon <br...@outerthought.org>.
(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-skin">cob:yetanothercompany.com/skins/fancy/1.2.2</connection>
> <connection
> name="internal-skin">cob:mycompany.com/skins/corporate/34.3.345</connection>
> <connection
> name="repository">cob:mycompany.com/repositories/email/exchange/3.2.1</connection>
> </connections>
> <configuration>
> <param name="user">guest</param>
> <param name="password">sj3u493</param>
> </configuration>
> </block>
> <block uri="cob:mycompany.com/repositories/email/exchange/3.2.1"
> wire-id="394781274834">
> <configuration>
> <param name="host">mail.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
bruno@outerthought.org bruno@apache.org
Re: [RT] Implementing Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Geoff Howard <co...@leverageweb.com>.
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
Posted by Bruno Dumon <br...@outerthought.org>.
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
bruno@outerthought.org bruno@apache.org
Re: [RT] Implementing Cocoon Blocks
Posted by Geoff Howard <co...@leverageweb.com>.
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
Posted by Bruno Dumon <br...@outerthought.org>.
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
bruno@outerthought.org bruno@apache.org
Re: [RT] Implementing Cocoon Blocks
Posted by Berin Loritsch <bl...@apache.org>.
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
Posted by Geoff Howard <co...@leverageweb.com>.
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?
Geoff
> Geoff Howard wrote:
>
>> 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.
Re: [RT] Implementing Cocoon Blocks
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
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.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Geoff Howard wrote:
> 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.
Re: [RT] Implementing Cocoon Blocks
Posted by Geoff Howard <co...@leverageweb.com>.
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
Posted by Vadim Gritsenko <va...@verizon.net>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Vadim Gritsenko <va...@verizon.net>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Vadim Gritsenko <va...@verizon.net>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Vadim Gritsenko <va...@verizon.net>.
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
Posted by Geoff Howard <co...@leverageweb.com>.
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. 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?
Unpacked blocks:
Good question -- maybe in WEB-INF/blocks ?
Geoff
Re: [RT] Implementing Cocoon Blocks
Posted by Vadim Gritsenko <va...@verizon.net>.
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:
> 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?
Vadim
Re: [RT] Implementing Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Geoff Howard <co...@leverageweb.com>.
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">
> <location>WEB-INF/blocks/384938958499</location>
> <mount>/mail/</mount>
> <connections>
> <connection
> name="external-skin">cob:yetanothercompany.com/skins/fancy/1.2.2</
> connection
> <connection
> name="internal-skin">cob:mycompany.com/skins/corporate/34.3.345</
> connection>
> <connection
> name="repository">cob:mycompany.com/repositories/email/exchange/3.2.1</
> connection>
> </connections>
> <configurations>
> <param name="user">guest</param>
> <param name="password">sj3u493</param>
> </configurations>
> </block>
>
> <block id="cob:mycompany.com/repositories/email/exchange/3.2.1">
> <location>WEB-INF/blocks/394781274834</location>
> <configurations>
> <param name="host">mail.blah.org</param>
> </configuration>
> </block>
>
> <block id="cob:yetanothercompany.com/skins/fancy/1.2.2">
> <location>WEB-INF/blocks/947384127832</location>
> </block>
>
> <block id=cob:mycompany.com/skins/corporate/34.3.345">
> <location>WEB-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
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Aug 29, 2003, at 05:53 Europe/Rome, Geoff Howard wrote:
>> 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)
Ok, great. Does anybody have a problem with the proposed file system
layout?
> <?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-skin">cob:yetanothercompany.com/skins/fancy/1.2.2</
> connection>
> <connection
> name="internal-skin">cob:mycompany.com/skins/corporate/34.3.345</
> connection>
> <connection
> name="repository">cob:mycompany.com/repositories/email/exchange/
> 3.2.1</connection>
> </connections>
> <configuration>
> <param name="user">guest</param>
> <param name="password">sj3u493</param>
> </configuration>
> </block>
> <block uri="cob:mycompany.com/repositories/email/exchange/3.2.1"
> wire-id="394781274834">
> <configuration>
> <param name="host">mail.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} > ?
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)
> I also considered recording the wire-id instead of the uri for
> connections between blocks - what are the arguments for each?
wire-id is an artifact created by the deployment manager but doesn't
add information to the wiring schema:
<blocks xmlns="http://apache.org/cocoon/blocks/wiring/1.0">
<block id="cob:mycompany.com/webmail/1.3.43">
<location>WEB-INF/blocks/384938958499</location>
<mount>/mail/</mount>
<connections>
<connection
name="external-skin">cob:yetanothercompany.com/skins/fancy/1.2.2</
connection
<connection
name="internal-skin">cob:mycompany.com/skins/corporate/34.3.345</
connection>
<connection
name="repository">cob:mycompany.com/repositories/email/exchange/3.2.1</
connection>
</connections>
<configurations>
<param name="user">guest</param>
<param name="password">sj3u493</param>
</configurations>
</block>
<block id="cob:mycompany.com/repositories/email/exchange/3.2.1">
<location>WEB-INF/blocks/394781274834</location>
<configurations>
<param name="host">mail.blah.org</param>
</configuration>
</block>
<block id="cob:yetanothercompany.com/skins/fancy/1.2.2">
<location>WEB-INF/blocks/947384127832</location>
</block>
<block id=cob:mycompany.com/skins/corporate/34.3.345">
<location>WEB-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)
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
4) changed "configuration" in "configurations" to identify a container
that can contain one or more parameters.
> <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)
> 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.
-
Stefano.
Re: [RT] Implementing Cocoon Blocks
Posted by Geoff Howard <co...@leverageweb.com>.
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-skin">cob:yetanothercompany.com/skins/fancy/1.2.2</connection>
<connection
name="internal-skin">cob:mycompany.com/skins/corporate/34.3.345</connection>
<connection
name="repository">cob:mycompany.com/repositories/email/exchange/3.2.1</connection>
</connections>
<configuration>
<param name="user">guest</param>
<param name="password">sj3u493</param>
</configuration>
</block>
<block uri="cob:mycompany.com/repositories/email/exchange/3.2.1"
wire-id="394781274834">
<configuration>
<param name="host">mail.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 create-time
values and deploy-time values, or is that pointless once the wiring has
happened?
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).
What blocks version is this? 1.0? 1.1? 2.1? 2.2?
Hack away,
Geoff
Re: [RT] Implementing Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
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.xslt"><map: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 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 increase of the major version number of
>> the URI identifying that behavior (cob:mycompany.com/skin/2.3).
>> The developers of cob:mycompany.com/skins/corporate/34.3.345 decide
>> to reuse doc2html.xslt (because they know that behavior is still the
>> same) but need to overload news2html.xslt to provide the new behavior
>> that conforms to cob:mycompany.com/skin/2.3.
>> As you see with this simple (yet very likely to happen) example, the
>> "implements" property is not, generally, transitive.
>
> Gotcha.
>
>>> Also, does the fact that no component initially defining
>>> cob:anothercompany.com/MailRepository/2.0 exists here matter?
>> What do you mean?
>
> Well, we've said it implements this (really set of) block behavior(s)
> but in the example so far, no block exists with the original
> "interface" definition. I know there is not a very tight analogy with
> java interface implementation, but should there be some requirement to
> have a definition of what a block is implementing when it says it
> implements it?
no. the java analysis falls short because, for block behaviors, we do
not have a way to "describe" this behavior. Eventually, it could be
possible to look it up thru the URI (directly, if we move to http: URI
or indirectly if we keep cob: URI as we need a lookup machanism), but
this is not necessary at this point, it would be only to validate
whether or not the block actually *does* implement that behavior, but
checking this is simply too hard so we decided to go down the weak
typing approach.
> If not, whose responsibility is it to ensure that the implementation
> is complete? The block developer? If so, how do they know when
> they've done it?
Eh, you are touching a nerve here and, by far, the most critical thing
of the whole design.
To draw a parallel, it's weak typing vs. strong typing. Over the years,
I came to appreciate both approaches: weak typing for rapid scripting
and strong typing for solid foundations.
Where do blocks reside? well, one could say that block reside in the
'solid foundations' realm (if looking from the block developer
perspective) or in the rapid scripting (if looking from the block user
perspective). Who is right? I don't know.
The only thing I know for sure is that writing a "block behavior
descriptor" is such a complex task that it would be foolish to attempt
to do so.
Consider the example before: a stylesheet that changes behavior in
copying-over or dropping content in another namespace? how do you
signal that? how do you test it? an image that is more than 123 pixels
wide but less than 134 pixels otherwise the page layout is ruined? how
many things would there be to checkout?
As for strong typing advocates: java is not that strongly typed as it
seems at first. If you use collections without generics, well, you are
on your own. CCE and NPE are avoided only with *your* care during
development.
In short, I think block behavior validation will simply work on its
own, by comparing to a reference implementation of that behavior. That
behavior URI might point to a document that explains what services are
provided and what not, but this is not to be machine digestable, but
simply a for-humans descriptions of what the blocks do.
True, it's entirely possible to incrementally create an ontology of
block operations and use DAML+OIL software to perform validation and
truth analysis, but given the amount of people that volunteer their
brain to do that truth analysis on their own, why should we substitute
"real intelligence" with "artificial" one?
>>> With this and the above questions I'm trying to get at where the
>>> hidden
>>> contracts are.
>> Great. This is useful to me as well, as it stress-tests the design.
>> keep up the nice thinking.
>
> ...
>
>>> Ok, I've wiki'd the latest with my proposal about @id and @block
>>> included.
>> ok, sounds good to me.
>> anybody else?
>
> I suspect that either others are not really paying attention anymore
> because of the length of the thread, or the relative "unsexyness" of
> this first step.
>
> I think a followup email pointing to the wiki results so far and
> asking for comment would be a good step here RSN. I suppose this
> doesn't need a vote (?) but that would be another way to ensure
> someone will peek their head in.
>
> In the meantime I am happy to play the Meno to your Socrates,
:-)
I agree on the general unsexyness of these things, but only because we
don't have anything working.
As soon as things start to work, I expect tons of comments, mostly of
things that were already said before ;-) but, hey, that's life.
--
Stefano.
Re: [RT] Implementing Cocoon Blocks
Posted by Geoff Howard <co...@leverageweb.com>.
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.xslt"><map: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 increase of the major version number of the URI identifying
> that behavior (cob:mycompany.com/skin/2.3).
>
> The developers of cob:mycompany.com/skins/corporate/34.3.345 decide to
> reuse doc2html.xslt (because they know that behavior is still the same)
> but need to overload news2html.xslt to provide the new behavior that
> conforms to cob:mycompany.com/skin/2.3.
>
> As you see with this simple (yet very likely to happen) example, the
> "implements" property is not, generally, transitive.
Gotcha.
>> Also, does the fact that no component initially defining
>> cob:anothercompany.com/MailRepository/2.0 exists here matter?
>
> What do you mean?
Well, we've said it implements this (really set of) block behavior(s)
but in the example so far, no block exists with the original "interface"
definition. I know there is not a very tight analogy with java
interface implementation, but should there be some requirement to have a
definition of what a block is implementing when it says it implements it?
If not, whose responsibility is it to ensure that the implementation is
complete? The block developer? If so, how do they know when they've
done it?
>> With this and the above questions I'm trying to get at where the hidden
>> contracts are.
>
> Great. This is useful to me as well, as it stress-tests the design. keep
> up the nice thinking.
...
>> Ok, I've wiki'd the latest with my proposal about @id and @block
>> included.
>
> ok, sounds good to me.
>
> anybody else?
I suspect that either others are not really paying attention anymore
because of the length of the thread, or the relative "unsexyness" of
this first step.
I think a followup email pointing to the wiki results so far and asking
for comment would be a good step here RSN. I suppose this doesn't need
a vote (?) but that would be another way to ensure someone will peek
their head in.
In the meantime I am happy to play the Meno to your Socrates,
Geoff
Re: [RT] Implementing Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
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
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 increase of the major version number of the URI identifying
that behavior (cob:mycompany.com/skin/2.3).
The developers of cob:mycompany.com/skins/corporate/34.3.345 decide to
reuse doc2html.xslt (because they know that behavior is still the same)
but need to overload news2html.xslt to provide the new behavior that
conforms to cob:mycompany.com/skin/2.3.
As you see with this simple (yet very likely to happen) example, the
"implements" property is not, generally, transitive.
> Also, does the fact that no component initially defining
> cob:anothercompany.com/MailRepository/2.0 exists here matter?
What do you mean?
> With this and the above questions I'm trying to get at where the hidden
> contracts are.
Great. This is useful to me as well, as it stress-tests the design.
keep up the nice thinking.
>>> 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 fine for me.
>
> me too.
>
> Ok, I've wiki'd the latest with my proposal about @id and @block
> included.
ok, sounds good to me.
anybody else?
--
Stefano.
Re: [RT] Implementing Cocoon Blocks
Posted by Geoff Howard <co...@leverageweb.com>.
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 fine for me.
me too.
Ok, I've wiki'd the latest with my proposal about @id and @block included.
Geoff
Re: [RT] Implementing Cocoon Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
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"
>> 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">
change uri to ID
> <implements uri="cob:anothercompany.com/MailRepository/2.0"/>
change uri to behavior
> <provides role="com.anothercompany.repository.Repository"/>
change role to component? [role is avalon terminology and might confuse
non-avaloners]
> <parameters>
> <param name="host" type="string" default="127.0.0.1" />
> </parameters>
> </cob>
>
> Here's the provides which might also be "exposes".
both are fine for me.
> 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.
yep
comments?
--
Stefano.
Re: [RT] Implementing Cocoon Blocks
Posted by Geoff Howard <co...@leverageweb.com>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Reinhard Poetz <re...@apache.org>.
> From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
>
> 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.
you are right, so only for the records ;)
Maybe we can go the "FOM" way. We reduce the public available classes to
a minimum and so also reduce the possible contracts to a minimum.
But it is not only Cocoon classes. There are also a few classes in
libraries which are necessary in a block (see avalon-framework,
excalibur-sourceresolve, excalibur-store, excalibur-xmlutil)
Reinhard
Re: [RT] Implementing Cocoon Blocks
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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