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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
