You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/08/13 15:56:17 UTC
Cocoon Contracts (was Re: Why does Action extend ThreadSafe ?)
I have been giving _alot_ of thought about actions, components,
and contracts in Cocoon. Please pay attention to the different contracts
in affect for the core components (tune in below for some comments):
1) Action: An action performs server side logic with _no_ display or
XML generation facilities. It must be compatible with Thread Safety
constraints so that the majority of Actions can be ThreadSafe.
2) Generator: A generator performs XML generation from some external source,
whether it is a stream, an object, or database. It must send SAX events
to the next component in a chain. A Generator is always the first component
in a chain. Due to the SAX implementation, it cannot be ThreadSafe--but
can be Pooled.
3) Transformer: A transformer recieves XML from a chain, performs some sort
of processing on the stream, and forwards the results to the next item in
a chain. A transformer has the same issues regarding the SAX implementation,
and therefore has the same constraints.
4) Serializer: A serializer receives XML from a chain, and converts it to
an external stream. A Serializer is the last element in a stream. Again,
it has the same constraints placed upon it as Generator due to the same
issues.
5) Reader: A reader pulls an arbitrary resource from any source (much like a
Generator), but it serializes a copy to an outputstream immediately.
6) Matcher: A matcher tests the URI for specific patterns, and is used to
select specific pipelines based on requests. A matcher _must_ be ThreadSafe,
and provide only simple or quick processing.
7) Selector: A selector will test the environment for a specific set of
criteria and allow you to choose one or more different pipelines (or sub
pipelines). Like a matcher, the selector _must_ be ThreadSafe, and provide
only simple or quick processing.
8) Sitemap: A sitemap will provide the overall resource to environment matching,
and must be ThreadSafe.
Components with artificial constraints:
1) Action: Action is currently _always_ ThreadSafe. After much thought on the
subject, I beleive that it is an error to enforce LifeStyle (ThreadSafe,
Poolable, SingleThreaded) on the work interface. It is also an error to force
LifeCycle (Configurable, Contextualizable, Initializable, etc.) on the work
interface. While 99% of forseen uses for Action are ThreadSafe actions, the
additional 1% should be possible as it causes little to no programming overhead.
2) Generator: A Generator implements SitemapComponent which has two methods for
it's normal use. Since a pipeline is constructed and then executed by one
command (generate()), setup() and generate() can theorhetically be merged for
a Generator. This provides an interface much like Action--and creates the
ability for a ThreadSafe Generator. This approach is prefered to forcing them
all to be pooled or created by factory. This also means that a Generator cannot
be considered a SitemapComponent
3) Reader: A reader is essentially an entire pipeline in one package. It implements
the SitemapComponent interface forcing it to be wither Pooled or created by factory.
The Reader can potentially be created in a ThreadSafe manner if the Setup(), read(),
and setOutputStream() methods are all merged.
Changes that can be made:
1) Action: By removing the ThreadSafe interface from the Action work interface, we
can allow other LifeStyles to be enforced on Actions. This is a minor change, and
does not introduce complexity or violate backwards compatibility.
Changes that cannot be made:
1) Generator: We cannot easily change how Generator is made due to the API change
requirements. Theorhetically we can deprecate the old generate and setup methods,
but that requires MethodNotImplementedException catching for the majority of cases.
2) Reader: Due to the same issues with Generator, we cannot make those changes due to
API compatibility requirements.
Change Plan:
1) Document the current contracts in all Cocoon Components in the work interface, so
everyone can know the thought process for design decisions, as well as what the
components were designed for.
2) Remove the ThreadSafe interface from Action.
3) Make all work interface implement an INTERFACE_VERSION constant that is filled with
Avalon's Version object.
4) Make a release with all the interface versions set to 1.0.0.
5) After the release, change the interface versions for Reader and Generator to 2.0.0
and deprecate the extra methods, providing a new method with all the information
combined. This allows us to perform a quick test on INTERFACE_VERSION so that we
call the correct method on any one of the components.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why does a Serializer doesn't have a setup method? Was:Re: Cocoon Contracts (was Re: Why does Action extend ThreadSafe ?)
Posted by Mariano Kamp <mk...@codamax.com>.
On Wednesday 15 August 2001 07:37, giacomo wrote:
> On Mon, 13 Aug 2001, Berin Loritsch wrote:
> > Mariano Kamp wrote:
> > > Hello Berin,
> > >
> > > your explanations are quite helpful. Just one little question:
> > > >[..]
> > > >
> > > > 2) Generator: A generator performs XML generation from some external
> > > > source, whether it is a stream, an object, or database. It must send
> > > > SAX events to the next component in a chain. A Generator is always
> > > > the first component in a chain. Due to the SAX implementation, it
> > > > cannot be ThreadSafe--but can be Pooled.
> > > >
> > > >[..]
> > > >
> > > > 4) Serializer: A serializer receives XML from a chain, and converts
> > > > it to an external stream. A Serializer is the last element in a
> > > > stream. Again, it has the same constraints placed upon it as
> > > > Generator due to the same issues.
> > >
> > > I guess you are referring to the need to use instance variables? What I
> > > don't get is that there is no setup method in Serializer. I was already
> > > asking this once, but Giacomo just replied: "It is the way it is
> > > designed." Could you probably cast some light into the schadow?
>
> Serializers purpose are to serialize SAX events into streams. So there
> is no need for stuff passed in by the setup method in
> SitemapModelComponent (at least so far).
Ok, here is an example. I have a serializer which task it is to produce
charts. It gets all the data as SAX-Events. Currently it also gets the width
and the height of the images to be produced within the data. This is the only
point where I need to "mess up" my data, with parameters about how the
container of the images should be rendered. I would have appreciated to pass
it to the serializer in the setup method, actually reading from the request
parameters.
Currently I do know put this height and width in my "report definitions",
which are generated in the very beginning of my pipeline and are the base for
all the dbQueries needed etc. So I push this information from step one to the
last step, without any need to use it in the steps between.
The last transformer does some xslt and I could also pass the width and
height in there, but haven't done so, because my current approach is not too
bad either. My point is. I don't absolutely need a setup() method in a
Serializer, but I was wondering why there is none.
Thanks for enlightening me ;-)
Mariano
> > I was refering to the SAX methods. In regular use, it receives multiple
> > SAX events, so it does not have a single entry point, or a document
> > scoping method.
> >
> > > So my real question is: If a serializer needs to have instance
> > > variables why shouldn't has it a setup() Method?
> >
> > The absence of the Setup method is due to the lack of runtime behavior
> > modification ability. A serializer should function the same way every
> > time it is used, regardless of runtime parameters. That is the main
> > reason it does not have a setup() method.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why does a Serializer doesn't have a setup method? Was:Re: Cocoon
Contracts (was Re: Why does Action extend ThreadSafe ?)
Posted by giacomo <gi...@apache.org>.
On Mon, 13 Aug 2001, Berin Loritsch wrote:
> Mariano Kamp wrote:
> >
> > Hello Berin,
> >
> > your explanations are quite helpful. Just one little question:
> >
> > >[..]
> >
> > > 2) Generator: A generator performs XML generation from some external
> > > source, whether it is a stream, an object, or database. It must send SAX
> > > events to the next component in a chain. A Generator is always the first
> > > component in a chain. Due to the SAX implementation, it cannot be
> > > ThreadSafe--but can be Pooled.
> >
> > >[..]
> >
> > > 4) Serializer: A serializer receives XML from a chain, and converts it to
> > > an external stream. A Serializer is the last element in a stream.
> > > Again, it has the same constraints placed upon it as Generator due to the
> > > same issues.
> >
> > I guess you are referring to the need to use instance variables? What I don't
> > get is that there is no setup method in Serializer. I was already asking this
> > once, but Giacomo just replied: "It is the way it is designed." Could you
> > probably cast some light into the schadow?
Serializers purpose are to serialize SAX events into streams. So there
is no need for stuff passed in by the setup method in
SitemapModelComponent (at least so far).
Giacomo
>
> I was refering to the SAX methods. In regular use, it receives multiple SAX
> events, so it does not have a single entry point, or a document scoping method.
>
> > So my real question is: If a serializer needs to have instance variables
> > why shouldn't has it a setup() Method?
>
> The absence of the Setup method is due to the lack of runtime behavior modification
> ability. A serializer should function the same way every time it is used, regardless
> of runtime parameters. That is the main reason it does not have a setup() method.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why does a Serializer doesn't have a setup method? Was:Re: Cocoon
Contracts (was Re: Why does Action extend ThreadSafe ?)
Posted by Berin Loritsch <bl...@apache.org>.
Mariano Kamp wrote:
>
> Hello Berin,
>
> your explanations are quite helpful. Just one little question:
>
> >[..]
>
> > 2) Generator: A generator performs XML generation from some external
> > source, whether it is a stream, an object, or database. It must send SAX
> > events to the next component in a chain. A Generator is always the first
> > component in a chain. Due to the SAX implementation, it cannot be
> > ThreadSafe--but can be Pooled.
>
> >[..]
>
> > 4) Serializer: A serializer receives XML from a chain, and converts it to
> > an external stream. A Serializer is the last element in a stream.
> > Again, it has the same constraints placed upon it as Generator due to the
> > same issues.
>
> I guess you are referring to the need to use instance variables? What I don't
> get is that there is no setup method in Serializer. I was already asking this
> once, but Giacomo just replied: "It is the way it is designed." Could you
> probably cast some light into the schadow?
I was refering to the SAX methods. In regular use, it receives multiple SAX
events, so it does not have a single entry point, or a document scoping method.
> So my real question is: If a serializer needs to have instance variables
> why shouldn't has it a setup() Method?
The absence of the Setup method is due to the lack of runtime behavior modification
ability. A serializer should function the same way every time it is used, regardless
of runtime parameters. That is the main reason it does not have a setup() method.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Why does a Serializer doesn't have a setup method? Was:Re: Cocoon Contracts (was Re: Why does Action extend ThreadSafe ?)
Posted by Mariano Kamp <mk...@codamax.com>.
Hello Berin,
your explanations are quite helpful. Just one little question:
>[..]
> 2) Generator: A generator performs XML generation from some external
> source, whether it is a stream, an object, or database. It must send SAX
> events to the next component in a chain. A Generator is always the first
> component in a chain. Due to the SAX implementation, it cannot be
> ThreadSafe--but can be Pooled.
>[..]
> 4) Serializer: A serializer receives XML from a chain, and converts it to
> an external stream. A Serializer is the last element in a stream.
> Again, it has the same constraints placed upon it as Generator due to the
> same issues.
I guess you are referring to the need to use instance variables? What I don't
get is that there is no setup method in Serializer. I was already asking this
once, but Giacomo just replied: "It is the way it is designed." Could you
probably cast some light into the schadow?
So my real question is: If a serializer needs to have instance variables
why shouldn't has it a setup() Method?
Mariano
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Contracts (was Re: Why does Action extend ThreadSafe ?)
Posted by giacomo <gi...@apache.org>.
On Tue, 14 Aug 2001, Berin Loritsch wrote:
> Sylvain Wallez wrote:
> >
> > Berin Loritsch wrote:
> > >
> > > I have been giving _alot_ of thought about actions, components,
> > > and contracts in Cocoon. Please pay attention to the different contracts
> > > in affect for the core components (tune in below for some comments):
> >
> > Great analysis !
>
> Thank you. I've been with this for a while, so these represent most of our
> current understanding.
>
> > > 1) Action: An action performs server side logic with _no_ display or
> > > XML generation facilities. It must be compatible with Thread Safety
> > > constraints so that the majority of Actions can be ThreadSafe.
> > >
> > > 2) Generator: A generator performs XML generation from some external source,
> > > whether it is a stream, an object, or database. It must send SAX events
> > > to the next component in a chain. A Generator is always the first component
> > > in a chain. Due to the SAX implementation, it cannot be ThreadSafe--but
> > > can be Pooled.
> > >
> > > 3) Transformer: A transformer recieves XML from a chain, performs some sort
> > > of processing on the stream, and forwards the results to the next item in
> > > a chain. A transformer has the same issues regarding the SAX implementation,
> > > and therefore has the same constraints.
> > >
> > > 4) Serializer: A serializer receives XML from a chain, and converts it to
> > > an external stream. A Serializer is the last element in a stream. Again,
> > > it has the same constraints placed upon it as Generator due to the same
> > > issues.
> > >
> > > 5) Reader: A reader pulls an arbitrary resource from any source (much like a
> > > Generator), but it serializes a copy to an outputstream immediately.
> > >
> > > 6) Matcher: A matcher tests the URI for specific patterns, and is used to
> > > select specific pipelines based on requests. A matcher _must_ be ThreadSafe,
> > > and provide only simple or quick processing.
> >
> > Why _must_ ? Even if matchers are likely to be more simple than actions,
> > the same analysis as the one you make for Action below (don't enforce
> > LifeStyle on work interfaces) can also apply to Matcher.
>
> Not quite. The Matchers and Selectors have a contract with the Sitemap itself that
> is very strong. The Sitemap assumes that everything in its _direct_ control (which
> does not include the pipeline components) is ThreadSafe. This is the way the Sitemap
> is written. *ESPECIALLY* the factory matchers and selectors. These have absolutely
> no margin for anything but a thread safe implementation because they are embedded
> directly in the code.
This is the right analysis I was looking for but couldn't name it! Thank
you Berin.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Contracts (was Re: Why does Action extend ThreadSafe ?)
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> Berin Loritsch wrote:
> >
> > I have been giving _alot_ of thought about actions, components,
> > and contracts in Cocoon. Please pay attention to the different contracts
> > in affect for the core components (tune in below for some comments):
>
> Great analysis !
Thank you. I've been with this for a while, so these represent most of our
current understanding.
> > 1) Action: An action performs server side logic with _no_ display or
> > XML generation facilities. It must be compatible with Thread Safety
> > constraints so that the majority of Actions can be ThreadSafe.
> >
> > 2) Generator: A generator performs XML generation from some external source,
> > whether it is a stream, an object, or database. It must send SAX events
> > to the next component in a chain. A Generator is always the first component
> > in a chain. Due to the SAX implementation, it cannot be ThreadSafe--but
> > can be Pooled.
> >
> > 3) Transformer: A transformer recieves XML from a chain, performs some sort
> > of processing on the stream, and forwards the results to the next item in
> > a chain. A transformer has the same issues regarding the SAX implementation,
> > and therefore has the same constraints.
> >
> > 4) Serializer: A serializer receives XML from a chain, and converts it to
> > an external stream. A Serializer is the last element in a stream. Again,
> > it has the same constraints placed upon it as Generator due to the same
> > issues.
> >
> > 5) Reader: A reader pulls an arbitrary resource from any source (much like a
> > Generator), but it serializes a copy to an outputstream immediately.
> >
> > 6) Matcher: A matcher tests the URI for specific patterns, and is used to
> > select specific pipelines based on requests. A matcher _must_ be ThreadSafe,
> > and provide only simple or quick processing.
>
> Why _must_ ? Even if matchers are likely to be more simple than actions,
> the same analysis as the one you make for Action below (don't enforce
> LifeStyle on work interfaces) can also apply to Matcher.
Not quite. The Matchers and Selectors have a contract with the Sitemap itself that
is very strong. The Sitemap assumes that everything in its _direct_ control (which
does not include the pipeline components) is ThreadSafe. This is the way the Sitemap
is written. *ESPECIALLY* the factory matchers and selectors. These have absolutely
no margin for anything but a thread safe implementation because they are embedded
directly in the code.
> Cocoon is a powerful engine, and people will use it to build a vast
> variety of applications. IMO, it's bad to put constraints like
> ThreadSafe on interfaces that can have so many different and unforseen
> implementations.
Maybe so, but as there are no concrete Matcher or Selector Components,
there is no other alternative. When we have concrete Components (instead of factory
classes), we can explore whether it is better to make some of them poolable. But a
word of caution: simple objects don't benefit as much from pooling as heavier objects.
> BTW, currently neither Matcher and Selector implement ThreadSafe.
>
> Also, a matcher can test anything in the environment, not only the URI.
I stand corrected on that point. Again, while neither Matcher nor Selector implement
ThreadSafe, there are no concrete examples of these as components either. It is
dubious to argue whether the current implementations would be easier to do as a Component,
the fact is the Factory method does yield faster code.
> > 7) Selector: A selector will test the environment for a specific set of
> > criteria and allow you to choose one or more different pipelines (or sub
> > pipelines). Like a matcher, the selector _must_ be ThreadSafe, and provide
> > only simple or quick processing.
>
> Same remark.
Same remark. (See above).
> > Change Plan:
>
> In which Cocoon version do you want to make the change ? IMO, this
> should be available in 2.0, before the user bases grows too much. If it
> is deferred to 2.1, this will make a backward incompatibility which will
> require much work for users of the 2.0.
>
> >
> > 1) Document the current contracts in all Cocoon Components in the work interface, so
> > everyone can know the thought process for design decisions, as well as what the
> > components were designed for.
> >
> > 2) Remove the ThreadSafe interface from Action.
>
> And add it to all implementations that currently exist so they have the
> same behaviour.
This (1 and 2) would be done now to both versions.
> > 3) Make all work interface implement an INTERFACE_VERSION constant that is filled with
> > Avalon's Version object.
> >
> > 4) Make a release with all the interface versions set to 1.0.0.
> >
> > 5) After the release, change the interface versions for Reader and Generator to 2.0.0
> > and deprecate the extra methods, providing a new method with all the information
> > combined. This allows us to perform a quick test on INTERFACE_VERSION so that we
> > call the correct method on any one of the components.
> >
> Can you explain further how this will work ? If a component implementing
> the deprecated interfaces runs inside a Cocoon with the new ones, the
> interfaces version will be 2.0.0 even if the component was developped
> using version 1.0.0. Or did I miss something ?
I have been going over this on the Avalon site, there is a way of doing it--we're just
not there yet.
> I also followed the "Interface version" thread on avalon-dev, but it
> doesn't seem to be really simple...
>
> What about some interface adapters to help people migrate 1.0.0
> implementations to 2.0.0, e.g. a LegacyAbstractGenerator, that defines
> the old interface as abstract methods and implements the new one by
> calls to these abstract methods ?
It's not that simple. I am of the impression that recording Interface Versions as
well as Implementation Versions is important. It allows for realistic tests later on
so that we can handle old components--or at least throw a warning that it isn't compatible.
The Abstract method would work, but not with currently compiled Generators that are
already part of a jar. We can also assume the absence of the version identifier means
that we have an old interface.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Contracts (was Re: Why does Action extend ThreadSafe ?)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch wrote:
>
> I have been giving _alot_ of thought about actions, components,
> and contracts in Cocoon. Please pay attention to the different contracts
> in affect for the core components (tune in below for some comments):
Great analysis !
>
> 1) Action: An action performs server side logic with _no_ display or
> XML generation facilities. It must be compatible with Thread Safety
> constraints so that the majority of Actions can be ThreadSafe.
>
> 2) Generator: A generator performs XML generation from some external source,
> whether it is a stream, an object, or database. It must send SAX events
> to the next component in a chain. A Generator is always the first component
> in a chain. Due to the SAX implementation, it cannot be ThreadSafe--but
> can be Pooled.
>
> 3) Transformer: A transformer recieves XML from a chain, performs some sort
> of processing on the stream, and forwards the results to the next item in
> a chain. A transformer has the same issues regarding the SAX implementation,
> and therefore has the same constraints.
>
> 4) Serializer: A serializer receives XML from a chain, and converts it to
> an external stream. A Serializer is the last element in a stream. Again,
> it has the same constraints placed upon it as Generator due to the same
> issues.
>
> 5) Reader: A reader pulls an arbitrary resource from any source (much like a
> Generator), but it serializes a copy to an outputstream immediately.
>
> 6) Matcher: A matcher tests the URI for specific patterns, and is used to
> select specific pipelines based on requests. A matcher _must_ be ThreadSafe,
> and provide only simple or quick processing.
Why _must_ ? Even if matchers are likely to be more simple than actions,
the same analysis as the one you make for Action below (don't enforce
LifeStyle on work interfaces) can also apply to Matcher.
Cocoon is a powerful engine, and people will use it to build a vast
variety of applications. IMO, it's bad to put constraints like
ThreadSafe on interfaces that can have so many different and unforseen
implementations.
BTW, currently neither Matcher and Selector implement ThreadSafe.
Also, a matcher can test anything in the environment, not only the URI.
>
> 7) Selector: A selector will test the environment for a specific set of
> criteria and allow you to choose one or more different pipelines (or sub
> pipelines). Like a matcher, the selector _must_ be ThreadSafe, and provide
> only simple or quick processing.
Same remark.
>
> 8) Sitemap: A sitemap will provide the overall resource to environment matching,
> and must be ThreadSafe.
>
> Components with artificial constraints:
>
> 1) Action: Action is currently _always_ ThreadSafe. After much thought on the
> subject, I beleive that it is an error to enforce LifeStyle (ThreadSafe,
> Poolable, SingleThreaded) on the work interface. It is also an error to force
> LifeCycle (Configurable, Contextualizable, Initializable, etc.) on the work
> interface. While 99% of forseen uses for Action are ThreadSafe actions, the
> additional 1% should be possible as it causes little to no programming overhead.
Totally agree ;)
>
> 2) Generator: A Generator implements SitemapComponent which has two methods for
> it's normal use. Since a pipeline is constructed and then executed by one
> command (generate()), setup() and generate() can theorhetically be merged for
> a Generator. This provides an interface much like Action--and creates the
> ability for a ThreadSafe Generator. This approach is prefered to forcing them
> all to be pooled or created by factory. This also means that a Generator cannot
> be considered a SitemapComponent
>
> 3) Reader: A reader is essentially an entire pipeline in one package. It implements
> the SitemapComponent interface forcing it to be wither Pooled or created by factory.
> The Reader can potentially be created in a ThreadSafe manner if the Setup(), read(),
> and setOutputStream() methods are all merged.
>
> Changes that can be made:
>
> 1) Action: By removing the ThreadSafe interface from the Action work interface, we
> can allow other LifeStyles to be enforced on Actions. This is a minor change, and
> does not introduce complexity or violate backwards compatibility.
>
> Changes that cannot be made:
>
> 1) Generator: We cannot easily change how Generator is made due to the API change
> requirements. Theorhetically we can deprecate the old generate and setup methods,
> but that requires MethodNotImplementedException catching for the majority of cases.
>
> 2) Reader: Due to the same issues with Generator, we cannot make those changes due to
> API compatibility requirements.
>
> Change Plan:
In which Cocoon version do you want to make the change ? IMO, this
should be available in 2.0, before the user bases grows too much. If it
is deferred to 2.1, this will make a backward incompatibility which will
require much work for users of the 2.0.
>
> 1) Document the current contracts in all Cocoon Components in the work interface, so
> everyone can know the thought process for design decisions, as well as what the
> components were designed for.
>
> 2) Remove the ThreadSafe interface from Action.
And add it to all implementations that currently exist so they have the
same behaviour.
>
> 3) Make all work interface implement an INTERFACE_VERSION constant that is filled with
> Avalon's Version object.
>
> 4) Make a release with all the interface versions set to 1.0.0.
>
> 5) After the release, change the interface versions for Reader and Generator to 2.0.0
> and deprecate the extra methods, providing a new method with all the information
> combined. This allows us to perform a quick test on INTERFACE_VERSION so that we
> call the correct method on any one of the components.
>
Can you explain further how this will work ? If a component implementing
the deprecated interfaces runs inside a Cocoon with the new ones, the
interfaces version will be 2.0.0 even if the component was developped
using version 1.0.0. Or did I miss something ?
I also followed the "Interface version" thread on avalon-dev, but it
doesn't seem to be really simple...
What about some interface adapters to help people migrate 1.0.0
implementations to 2.0.0, e.g. a LegacyAbstractGenerator, that defines
the old interface as abstract methods and implements the new one by
calls to these abstract methods ?
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org