Noel, This will keep me busy for a while and thanks for taking the time to respond. Please bear with me as I try to understand your view point.
Alex > -----Original Message----- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 07, 2004 11:25 PM > To: Jakarta Commons Developers List > Subject: RE: [codec] StatefulDecoders > > > Sorry about the delay, I've been away for a few days. > > And I'm a bit too busy at the moment to give this the attention it > deserves. > Mostly I agree with your message. > > You and Alex had each looked at this from particular points of view. I am > looking at it more generically, as I think you did in the mesage to which > I > am replying. > > Consider the Cocoon (http://cocoon.apache.org/) pipeline for the concept > of > a fully event-driven programming approach, although their implementation > has > far too much overhead for codec purposes (or the regex events I > mentioned). > IMO, we want a consistent interface that provides the fundamental > operations, and then we can build convenience on top of that interace. > > Your interface is closer to what I had in mind than Alex's, at least using > more of the generic terminology. The codec domain can be expressed using > the pipeline interface, or if we want a codec specific interface, Alex's > could be a convenience layer on top of the pipeline. > > What I had imagined is an approach where each element in the pipeline > supports a registering for variety of event notifications. Some of them > may > be generic, some of them may be domain specific. Most codec uses would > use > generic events. > > The key is being able to go an object and register for semantic events. > So > if you assume that a transformer is both a producer and a consumer, you > could register a transformer with a datasource (producer), and register > downstream consumers that want the decoded data with the transformer. > Yes, > we would want to allow both fan-in and fan-out where appropriate. > > As for the details of message transport ... it seems to me that we already > have multiple options, so I'm not sure that we want to roll our own versus > adopting and/or adapting an existing one. > > We have JMS, and the new concurrency package coming in JDK 1.5. One thing > that got botched in JDK 1.5 is that they removed the Putable and Takable > interfaces that Doug Lea had used in his library, instead merging their > functionality directly onto the queue interface, falsely believing that a > message queue is a Collection. A number of us argued for those > interfaces, > and Doug proposed a change, but it was vetoed by Sun. > > I see a few options, such as: > > - we pick up the necessary interfaces from Doug's concurrent > library, and deal with java.util.concurrent down the road. > > - we use JMS interfaces in a very simplied form. > > As potentially whacked as the idea might be, considering the complexity of > JMS, I believe that we could selectively use JMS interfaces without undo > complexity or hurting performance. Basically, we'd ignore the things that > don't make any sense in our context. Take a look at MessageProducer, > MessageConsumer and MessageListener. Intelligently, they are just > interfaces. We don't need multi-threading, network transports, etc., in > general, although by using those interfaces, they would be available where > applications warranted them. > > ref: > http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/package- > summary.html > > Alternatively, I had this odd thought that we could use the Callable > interface present in both Doug's code and java.util.concurrent. > > JSR-166: > http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/pack > ag > e-summary.html > > > A structured content API can extend the producer/consumer ideas by > passing > > data types understood by the structured content in question. > > See also the hierarchical Topic support in JMS. > > > If the above can be achieved without introducing a large overhead (both > > runtime and coding overhead) for simple operations then it sounds good. > > Agreed. Runtime issues are a key concern. > > As you know, we just had a JMS implementation offered, and there is > somnifugi. Do you think it is worth looking at an in-process JMS > implementation for the pipeline? > > --- Noel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
