Grzegorz Kossakowski wrote: > Carsten Ziegeler pisze: >> Now, to be honest, I find the whole situation not very comfortable >> at the moment. There are only a few contributing to C3 and nearly >> no other comments. My intention is to have a small, nice and easy, >> pipeline api which allows me to build sax pipelines. And I want to >> have as less dependencies and as less stuff in their to make it >> understandable as possible. I don't think that the symmetrie to the >> other implementations helps us. But that's of course my personal >> opinion. I think we (Steven, you, the Vienna-based students and >> myself) have a opinion and I guess it is based on/influenced by our >> experience and we are somehow stuck in our thinking. So it would be >> great if others could voice their opinion. > > Not only to just add one more dimension to the problem and discussion > space I would say that I disagree with both standpoints. This may > come from the fact that I see things from completely different angle. > > > Before I post any in-depth comments I still have to digest all the > e-mails that have been posted while I've been having a break. > > What already has stroke me is that people seem to agree that having > various *AbstractGenerator, *AbstractTransformer, *AbstractSerializer > classes is a good thing. I may miss the point completely but this > looks like a code and structure duplication.
Sorry, can't follow you here. What's the problem with that approach? > Could someone enlighten > me on why do we need different abstract classes? > > My very own guess for answer is that our Pipeline API is too weak (in > terms of constraints it enforces) so no meaningful abstract class can > be provided. This is what I'm not comfortable with for a long time > but others seems to not see this as a problem important enough. And > yes, I could resist to bring back this issue into discussion. The only alternative that I've seen so far exposes pipeline internals (see http://cocoon.markmail.org/message/sda4xck3fevcusns) which is a very dangerous approach IMHO because it works differently than most Java developers would expect and therefore could cause a lot of programming mistakes. Looking at our goal of providing generic pipelines for *Java* I think that we have been developing a solution that is powerful and abstract enough to support three different content types for pipeliones (StAX, SAX, Java Images) and works like most Java developers expect. Yes, I'm comfortable (enough) with the current solution and don't see a reason why we should reconsider our core contracts ATM. Of course that's my personal opinion and I'm not against changing things if this improves things within our scope of "generic pipelines for Java". -- Reinhard Pötz Managing Director, {Indoqa} GmbH http://www.indoqa.com/en/people/reinhard.poetz/ Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org ________________________________________________________________________
