Alex Karasulu wrote:
Ooops looks like this only went out to Mark's address.
Alex
On Fri, 2004-07-02 at 11:19, Alex Karasulu wrote:
On Fri, 2004-07-02 at 10:49, Mark R. Diggory wrote:
Alex,
This looks very good.
Hey thanks Mark! But I still think we can do better I just don't know
Ooops looks like this only went out to Mark's address.
Alex
On Fri, 2004-07-02 at 11:19, Alex Karasulu wrote:
> On Fri, 2004-07-02 at 10:49, Mark R. Diggory wrote:
> > Alex,
> >
> > This looks very good.
>
> Hey thanks Mark! But I still think we can do better I just don't know
> how at this p
Alex,
This looks very good. I think that a Stateful Codec with monitoring
would be a powerfull feature for multipart-codec. I'm not experienced
with NIO, IS this API restircted to working with just NIO?
-Mark
Alex Karasulu wrote:
On Thu, 2004-07-01 at 17:09, Eric Dalquist wrote:
I don't see p
On Thu, 2004-07-01 at 17:09, Eric Dalquist wrote:
> I don't see plugability as being a requirement. A streaming
> encoder/decoder is a larger requirement as the data being encoded into a
This is ugly too and we still have not come up with the final verdict
yet but take a look here and let us kno
Sounds good. I'm working on a streamable, thread safe version right now.
If you have an instant messenger I'd like to talk with you more about
some of the APIs that needed to be created for the streamable side of it.
-Eric Dalquist
Mark R. Diggory wrote:
Yes, I would say that getting some implem
Yes, I would say that getting some implementation in place which is
efficient and streamable is more important that working getting it to
plug into other Encoder/Decoder interfaces.
I ran out of time to push this forward. If your interested in moving it
forward, it would be helpful. I think tha
EMAIL PROTECTED]
Sent: Thursday, July 01, 2004 14:10
To: Jakarta Commons Developers List
Subject: Re: [codec-multipart] Who's In Charge
I don't see plugability as being a requirement. A streaming
encoder/decoder is a larger requirement as the data being encoded into
a
multipart message
; >
> >
> >
> >>of the encoder would be via an InputStream.
> >>
> >>
> >
> >This is indeed quite different from the current design. There have
been
> >discussions on this list about stateful and streamable decoder.
> >
> >Pe
al Message-
From: Eric Dalquist [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 01, 2004 11:26
To: Jakarta Commons Developers List
Subject: Re: [codec-multipart] Who's In Charge
Sorry about that last reply being to the wrong email.
Thinking more about the structure of the Encoder and Decoder
t; From: Eric Dalquist [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 01, 2004 11:26
> To: Jakarta Commons Developers List
> Subject: Re: [codec-multipart] Who's In Charge
>
> Sorry about that last reply being to the wrong email.
>
> Thinking more about the structure of the E
Sorry about that last reply being to the wrong email.
Thinking more about the structure of the Encoder and Decoder interfaces
I need to discuss what I see as the requirements on a multipart encoder
with you or someone else who is more familiar with the codec package and
get your options.
The ba
Well I'm not very familiar with the codec project (just went and looked
over the web page). I guess this depends on your definition of what a
codec is. The multipart encoding project is mainly useful for a java
based web browser to a program that needs to emulate such activity. It
allows a set
Hello,
The only person I see in codec-multipart/project.xml is:
Mark Diggory
mdiggory
mdiggory at apache.org
I am the codec 1.3 release manager for now and I cannot say much about
multipart apart from knowing that it exists and that volunteer
13 matches
Mail list logo
