commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject RE: [codec] StatefulDecoders
Date Mon, 08 Mar 2004 07:17:18 GMT

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.


> -----Original Message-----
> From: Noel J. Bergman []
> 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 ( 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:
> 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:
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message