Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4260FA7A.8030001@apache.org>
Date: Sat, 16 Apr 2005 13:43:54 +0200
From: Torsten Curdt <tcurdt@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Java components in blocks
References: <20050409083134.46541.qmail@minotaur.apache.org>
 <425A36D5.4010809@nada.kth.se> <425A3A7B.5030203@apache.org>
 <425A6B42.1040009@nada.kth.se> <425A7094.8040906@apache.org>
 <425A8A7A.1030203@nada.kth.se> <425A8EAF.7090502@apache.org>
 <255a9c1e1ee0934507a1f5447f3ef066@betaversion.org>
 <425BDF4B.8040705@apache.org>
 <3e1766b0f6774aa2f9b7a26a729043ae@betaversion.org>
 <425D0549.80401@apache.org>
 <9c28f5a45d1ec41b74503c823fa64351@betaversion.org>
 <425D5202.6050001@reverycodes.com>
 <c7fe51acb43d85bc70f9d75149201807@betaversion.org>
 <425E34D8.1070800@nada.kth.se>
 <394529d891516efa895dc2746c77cf58@betaversion.org>
 <425E8B81.3040105@apache.org> <425E8D37.7030106@dslextreme.com>
 <0f996695454c3cc853208a9a66041284@apache.org>
In-Reply-To: <0f996695454c3cc853208a9a66041284@apache.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig7F4492B63DF7E35F70E41A26"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7F4492B63DF7E35F70E41A26
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

> Reading these discussions after the fact, having Blocks provide only
> sitemap components seems to make a lot of sense

...not to me - sorry. But maybe I just missed something.

Pier is totally right: we have two different concerns.
One is the pipeline services interface and one is the
component interface of a block.

But reducing a block just to it's pipeline services basically
gives us virtual sitemap components on steroids. What about
its dependencies? Well, IIUC one argument in this discussion
was that the dependency will be satisfied through a pipeline
service - not through a component.


Block A:
 provides: a pipeline service to transform xml
 requires: a pipeline service to transform xml with a STX stylesheet

Block B:
 provides: a pipeline service to transform xml with a STX stylesheet


So block B does not provide the component with
hint "stx" but a service that could be anything
doing the job satisfying the dependency. Ok.

Now what about the component dependencies? Let's
say in order to implement the "transform-via-stx"
service block B requires a component of hint "stx".
Since the block B has its own component manager
and the component "stx" being declared in the block's
sitemap all is left is a java class level dependency
to the stx implementation. Now the question is - will
the block B provide the stx jar? Let's say yes for the
moment.

So what if the "transform-via-stx" component needs
another component? We could list all the required
component in the components section for that very block.
...but still the classes need to be available!

What if the classes are in a different block?

Essentially this means to me: As long as we don't want
to ship every block with every component it requires
I cannot see how we can get around of having blocks
also expose component services.

cheers
--
Torsten

--------------enig7F4492B63DF7E35F70E41A26
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCYPp6BGM6V3wgCUERAhbLAJ9l1+5Ysg5fHXGbayQV4MkXOzUl4ACeK2SA
EmXvZNFxjzgYF1v1nKGi0xY=
=opoE
-----END PGP SIGNATURE-----

--------------enig7F4492B63DF7E35F70E41A26--