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
To: 'Jakarta Commons Developers List'
Subject: RE: [codec] StatefulDecoders
Brett,
Ok let's take a breath and dive into this email :-).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
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
-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 of
a fully event-driven
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]
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 still relies
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 contributed
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
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
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.
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 are
-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 beats me to
it.
Yes, but no consensus
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
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
For the time being if some
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
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
, 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.apache.org/jira/secure/ViewIssue.jspa?key=DIR-30
Take a look
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 think
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
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
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 single
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
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
think
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,
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
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] StatefulDecoders
This brings up an interesting issue: How do we
'
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 discussed here have been solved in the library
I've posted previously. An up
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
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
been
on 1.3.1 for the foreseeable future. Some others, I imagine need 1.2
compatibility.
Gary
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Monday, February 23, 2004 18:13
To: Jakarta Commons Developers List
Cc: 'Apache Directory Developers List'
Subject: RE: [codec
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
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
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,
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 decoding session.
This
34 matches
Mail list logo
