Steven Dolg wrote: > I don't think I understand what you mean by "same xml transportation". Ah sorry, this was a try to find something better than "event types".
> Currently creating and executing a pipeline looks like: > > Pipeline pipeline = ...; > pipeline.add(new StAXGenerator(inputURL)); > pipeline.add(new StAXTransformer(myParameter)); > pipeline.add(new StAXSerializer(); > > pipeline.setup(outputStream); > pipeline.execute(); > > It is the same when using SAX (except different components, of course) > or when processing any other type of data (I think I should really go > and build that Imaging module...). Yes, sure - but: > Pipeline pipeline = ...; > pipeline.add(new StAXGenerator(inputURL)); > pipeline.add(new SAXTransformer(myParameter)); > pipeline.add(new StAXSerializer(); > wouldn't work - and maybe this wouldn't even end in an exception. The pipeline has no knowledge of the possible event types and which event types are compatible. So how can it check the validity of this pipeline? > Again I have the feeling that some concepts that Cocoon has for years > now (Pipelines look like Generator -> Transformer -> Serializer; make > sure the sitemap makes sense; know what the components actually do) are > all of a sudden too complicated for any user to apply them safely > without reading the source code. > But that may be just me... Hehe...no, no, it's not about the generator, transformer, serializer and how to chain them. For instance, the old cocoon pipeline interface made sure that you add the components to the pipeline in the correct order (first generator, then transformers, finally serializer). Just because something has been in one way or the other for years, doesn't mean that it's good and can't be made better/easier. :) > This simple switching of components works right now! > While creating the StAX components we often exchanged the components > (again all of them, not individual ones - SAX and StAX are not > compatible without adapters) > to compare the results from SAX and StAX. Yes, that's my point - you have to change all components in the pipeline. > IMO demanding that the user also selects the correct pipeline type for > his choice of components - that need to be compatible with each other > *and* the pipeline - is actually more than just demanding that he > chooses components that are compatible with each other and guaranteeing > that any (correctly implemented) pipeline will do the job. Hmm, the user has to select the correct pipeline type, yes, but I don't think that this is more complicated - and it would allow compile time checking of the components. > The components need to communicate with each other nonetheless. The > additional "Are you compatible with me?" check is fairly easy compared > to that (for StAX that are 3 lines of code in one abstract base class). Hmm, ok. > Being able to use the same Pipeline implementations (even the rather > sophisticated asynchronous caching pipeline) has saved us probably days > of work and that compatibility check took no more than 5 minutes once > the interfaces for the components (which we needed anyway) were defined. Yes, but that's you doing the stuff (or other people involved in implementing c3). For new users it is a little bit more complicated. Ok, granted, maybe I'm overestimating the benefit of the compile time check. Don't know. >> So we have something like: >> public interface Pipeline<T extends PipelineComponent> >> >> and have sub interfaces for PipelineComponent for sax, dom, stax? >> This ensures to have a single implementation but gives compiler time >> checks. >> > Well that would be nice of course. > But so far not working solution/prototype has been made available (or > did I simply miss it?). :) No of course you didn't miss it. Maybe I have time to look into this next week. > > And those that have merely scratch surface IMO. > There are still things like component order: Generator, Generator, > Transformer, Serializer, Generator is clearly not a valid pipeline, even > if all components are actually using the same technology. Yes, but this can be checked immediately when the component is added to the pipeline. Of course, this is not a compile time check. Maybe we don't need to change this and just properly naming things (like either adding SAX etc. to the class name or as a package) is enough. I actually don't know, but I think the easier we make it and the more we can check at compile time, the more we attract possible users. Carsten -- Carsten Ziegeler cziege...@apache.org
