Alex,
Sorry about the delay. I'm a bit snowed under at the moment.
I've attached producers/consumers that process Object instances instead of
type specific data.
Some differences between these interfaces and those you've already built
are:
1. These have no monitor facility. All errors result i
day, 24 March 2004 12:23 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [codec] StatefulDecoders
>
>
> Brett,
>
>
>
> Ok let's take a breath and dive into this email :-).
>
>
>
---
Brett,
Ok let's take a breath and dive into this email :-).
> -Original Message-
> From: Brett Henderson [mailto:[EMAIL PROTECTED]
> Perhaps our two approaches are closer in design than you suspect. I'll
> talk
> about ByteProducer and ByteConsumer from my implementation to illustrate
>
> Take a look at the "Reclaiming Type Safety" section in this
> article on the
>
> event notification pattern here:
>
>
>
> http://members.ispwest.com/jeffhartkopf/notifier/
>
Cool, that's a neat way of achieving type safety. Avoiding downcasts (eg.
Object to byte[]) is a good thing. It st
Brett,
It will take me some time to process your last email. Just a heads up in case a
response takes a while.
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Monday, 8 March 2004 3:25 PM
> To: Jakarta Commons Developers List
> Subject: RE: [codec] StatefulDecoders
> Consider the Cocoon (http://cocoon.apache.org/) pipeline for the
> concept
rs List'
> Subject: RE: [codec] StatefulDecoders
>
>
> 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
>
>
&g
> How about we put our minds together and finalize some of this
> stuff so I can
>
> start writing some codecs that can be added back to this project?
Yeah definitely, sounds like we're trying to solve the same problem here.
I haven't responded to your previous emails because I haven't contribut
arta 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 Al
Yeah looking at it now - my mailbox is a bit out of control today sorry.
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 08, 2004 2:06 AM
> To: Jakarta Commons Developers List
> Subject: RE: [codec] StatefulDecoders
>
> &g
> For the time being if some people can make suggestions on how
> these interfaces can be altered for the better we can begin
> having an open discussion around them.
See the much longer message I posted in response to Brett.
--- Noel
-
hem.
Alex
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 07, 2004 4:40 PM
> To: Jakarta Commons Developers List
> Subject: RE: [codec] StatefulDecoders
>
> > Good, more consensus from a user - I will commit if no one
Tim, Ryan,
> -Original Message-
> From: Tim O'Brien [mailto:[EMAIL PROTECTED]
> Good, more consensus from a user - I will commit if no one beats me to it.
>
> Ryan Hoegg wrote:
> > As a user of codec, I would like to post a non-binding +1 for the
> > interfaces in Alex's JIRA issue. They
> Good, more consensus from a user - I will commit if no one beats me to it.
Yes, but no consensus (or other comments) from Brett Henderson, who has a
lot of code in this space. And looking at Brett's code and Alex's code, I
am not convinced that we're all on the same page. Same chapter, sure.
Good, more consensus from a user - I will commit if no one beats me to it.
Ryan Hoegg wrote:
As a user of codec, I would like to post a non-binding +1 for the
interfaces in Alex's JIRA issue. They are simple and provide a clean,
intuitive asynchronous interfaces for client usage. I'd also like
As a user of codec, I would like to post a non-binding +1 for the
interfaces in Alex's JIRA issue. They are simple and provide a clean,
intuitive asynchronous interfaces for client usage. I'd also like to
request the analogous interfaces on the Encoder side.
Is codec going to continue to main
TECTED]
> Sent: Thursday, March 04, 2004 12:24 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [codec] StatefulDecoders
>
> Here's the JIRA report for the new stateful decoder interfaces that
> I've attached to this issue:
>
> http://nagoya.apach
Here's the JIRA report for the new stateful decoder interfaces that
I've attached to this issue:
http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=DIR-30
Take a look at the attached interface javaadocs and let me know what
you guys think.
BTW when looking at the interfaces notice that
Noel,
Sorry about the delay, I've been away for a few days.
> In general, I have long preferred the pipeline/event model to
> the approach
>
> that Alex had, where it would give data to the codec, and
> then poll it for
>
> state. However, I don't see something in your implementation
> that I
Hi,
> -Original Message-
> From: Gary Gregory [mailto:[EMAIL PROTECTED]
> > public java.util.List operation(java.nio.ByteBuffer buffer);
>
> This brings up an interesting issue: How do we potentially package and
> deliver some code that depends on Java 1.4. In a second [codec] jar? I
>
Hi,
Noel's description is correct. Please see my additional comments below:
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> > How does your proposal contrast/differs/combines with what has
> > been referred to on this list as "streamable" codecs?
> > See http://i
> From: Tim O'Brien [mailto:[EMAIL PROTECTED]
> Alex Karasulu wrote:
> > Hi,
> >
> > I've been working on the idea of stateful Decoders designed for use with
> > non-blocking reads where buffers are read from channels and used by
> > decoders. As you know you don't always get the complete PDU in a
Brett,
In general, I have long preferred the pipeline/event model to the approach
that Alex had, where it would give data to the codec, and then poll it for
state. However, I don't see something in your implementation that I think
we want. We want to be able to have structured content handlers a
Hi,
First of all let me apologize for the delayed response.
Unforeseen circumstances have kept me away from anything
electronic for days now.
Since the original post there has been some extensive feedback for
which I'm greatful and wish I could have responded to in a timely
fashion. I shall
s Developers List'
> Subject: RE: [codec] StatefulDecoders
>
> I probably sound like a broken record but here goes :-)
>
> If I'm barking up the wrong tree, let me know and I'll stop making noise
> on
> this list ...
>
> Many of the problems being d
roceed. Is this something that can be placed in a sandbox
for people to play with?
Cheers,
Brett
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 24 February 2004 2:25 PM
> To: Jakarta Commons Developers List
> Subject: RE: [codec] St
Tim,
By no means I want to see further development of [Codec] stopped or
hindered for the sake of other projects' convenience. All I want is to
ensure that basic features of [Codec] are still usable in those projects
that are less fortunate with the JDK compatibility requirements.
BTW, did anyone
Oleg, no one has talked about breaking existing interfaces - 1.2 will
still be supported be (at the very least) by all existing features.
This is more of a discussion of future growth, we are going to find a way
to enable features dependent on 1.4 while still support (creating a
distributable
Tim, Gary
Currently [Codec] is still Java 1.2 compatible. And yes, there are
[Codec] users who would like it to stay that way at least for some time.
Not that we enjoy working around Java 1.2 limitations that much, but we
simply have obligations to our users as well (there are several
projects, in
Gary Gregory wrote:
public java.util.List operation(java.nio.ByteBuffer buffer);
This brings up an interesting issue: How do we potentially package and
deliver some code that depends on Java 1.4. In a second [codec] jar? I think
we should keep the JRE requirement to a minimum for [codec]. Here, we
> This brings up an interesting issue: How do we potentially package and
> deliver some code that depends on Java 1.4. In a second [codec] jar?
There are several issues, but let me address what I consider to be the key
one: we have to design the core code as push-model. If we were to design
the c
Alex Karasulu wrote:
Hi,
I've been working on the idea of stateful Decoders designed for use with
non-blocking reads where buffers are read from channels and used by
decoders. As you know you don't always get the complete PDU in a single
channel read and so buffers need to be handled in a deco
ers List'
> Subject: RE: [codec] StatefulDecoders
>
> > > I've been working on the idea of stateful Decoders designed for use
> with
> > > non-blocking reads where buffers are read from channels and used by
> > > decoders.
> > > http://nagoy
> > I've been working on the idea of stateful Decoders designed for use with
> > non-blocking reads where buffers are read from channels and used by
> > decoders.
> > http://nagoya.apache.org/jira/secure/ViewIssue.jspa?id=13599
> How does your proposal contrast/differs/combines with what has
> bee
Let's split this into two chunks:
(1) DecoderException superclass
(2) StatefulDecoders
Gary
> -Original Message-
> From: Alex Karasulu [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 20, 2004 23:13
> To: [EMAIL PROTECTED]
> Cc: 'Apache Directory Developers List'
> Subject: [codec] Sta
35 matches
Mail list logo
