Serge Knystautas ha scritto:
> Norman Maurer wrote:
>> Ps: Serge maybe you allready knows... Your email client seems to set the
>> reply-to field to your emailaddress. So if someone just use reply you
>> are the only one which gets the answers..
>
> Thanks for letting me know. I'm just using GMai
Norman Maurer wrote:
Ps: Serge maybe you allready knows... Your email client seems to set the
reply-to field to your emailaddress. So if someone just use reply you
are the only one which gets the answers..
Thanks for letting me know. I'm just using GMail. Danny, I think you
use GMail for ASF
On 9/24/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Bernd Fondermann ha scritto:
> > On 9/23/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> robert burrell donkin-2 wrote:
> >>> this is the problem with lots of small patches: i don't understand
> >>> where you are taking the desi
Norman Maurer ha scritto:
> Am Montag, den 24.09.2007, 21:28 +0200 schrieb Stefano Bagnara:
>> Norman Maurer ha scritto:
>>> Ps: Serge maybe you allready knows... Your email client seems to set the
>>> reply-to field to your emailaddress. So if someone just use reply you
>>> are the only one which
Noel J. Bergman ha scritto:
> Robert Burrell Donkin wrote:
>
>> the disadvantage with using a byte array rather than a bytebuffer is
>> that direct bytebuffers would have to copy their data out into a byte
>> array. using a byte buffer at the lowest level would solve this issue
>> without really
Am Montag, den 24.09.2007, 21:28 +0200 schrieb Stefano Bagnara:
> Norman Maurer ha scritto:
> > Am Montag, den 24.09.2007, 14:58 -0400 schrieb Serge Knystautas:
> >> On 9/24/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> >>> Ignoring the technical/design issue I think at this time it is better
>
Norman Maurer ha scritto:
> Am Montag, den 24.09.2007, 14:58 -0400 schrieb Serge Knystautas:
>> On 9/24/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>>> Ignoring the technical/design issue I think at this time it is better
>>> for mime4j to increase its community/acceptance by helping other
>>> p
Am Montag, den 24.09.2007, 14:58 -0400 schrieb Serge Knystautas:
> On 9/24/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > Ignoring the technical/design issue I think at this time it is better
> > for mime4j to increase its community/acceptance by helping other
> > projects (e.g. commons-upload
On 9/24/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Ignoring the technical/design issue I think at this time it is better
> for mime4j to increase its community/acceptance by helping other
> projects (e.g. commons-upload) to use mime4j. IMHO collecting users that
> depends on the library is th
Robert Burrell Donkin wrote:
> the disadvantage with using a byte array rather than a bytebuffer is
> that direct bytebuffers would have to copy their data out into a byte
> array. using a byte buffer at the lowest level would solve this issue
> without really an added overhead for the bio case (
On 9/23/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> robert burrell donkin-2 wrote:
> >
> > it's direct use of byte arrays which worried me. how do you propose to
> > handle memory mapped files without double buffering?
> >
>
> I have to admit that I do not know about memory mapped files and
Stefano Bagnara wrote:
> Bernd Fondermann ha scritto:
>
>> On 9/23/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>>
>>> robert burrell donkin-2 wrote:
>>>
this is the problem with lots of small patches: i don't understand
where you are taking the design
Bernd Fondermann ha scritto:
> On 9/23/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>>
>>
>> robert burrell donkin-2 wrote:
>>> this is the problem with lots of small patches: i don't understand
>>> where you are taking the design
>>>
>> In general, non-committers are expected to split their work
On 9/23/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>
>
>
> robert burrell donkin-2 wrote:
> >
> > this is the problem with lots of small patches: i don't understand
> > where you are taking the design
> >
>
> In general, non-committers are expected to split their work up into smaller
> patches,
it that I do not know about memory mapped files and why they
should be relevant. I'll be reading on that.
--
View this message in context:
http://www.nabble.com/-Mime4J--Support-For-Non-Streaming-Inputs-tf4490104.html#a12845823
Sent from the James -
On 9/22/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>
>
>
> robert burrell donkin-2 wrote:
> >
> > your patch would require double buffering when used with direct
> > buffers and would require convertion of structured data into bytes.
> > so, it's unsatisfactory for use cases 1 and 2. however, i
On 9/23/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin wrote:
>
> > your patch would require double buffering when used with direct
> > buffers and would require convertion of structured data into bytes.
> > so, it's unsatisfactory for use cases 1 and 2. however, i'm not sur
Robert Burrell Donkin wrote:
> your patch would require double buffering when used with direct
> buffers and would require convertion of structured data into bytes.
> so, it's unsatisfactory for use cases 1 and 2. however, i'm not sure
> whether this is something that is worthwhile arguing about.
Jochen
--
View this message in context:
http://www.nabble.com/-Mime4J--Support-For-Non-Streaming-Inputs-tf4490104.html#a12838664
Sent from the James - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 9/22/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>
>
>
> robert burrell donkin-2 wrote:
> >
> > i'm not sure that they are necessarily mutally exclusive but i do
> > believe that good support introduces complexity and leads to
> > unnecessary debates about design
> >
>
> And the proper place
te buffers.
Whether it is actually faster, I cannot tell so far, because I am still
debugging. That can be seen when the benchmark is working.
Jochen
--
View this message in context:
http://www.nabble.com/-Mime4J--Support-For-Non-Streaming-Inputs-tf4490104.html#a12835172
Sent from the James - De
On 9/22/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> On 9/21/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > Serge Knystautas-2 wrote:
> > >
> > > Thanks for raising this project scope issue since IMHO these are the
> > > bigger than technical decisions. If I can restate,
On 9/21/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>
>
>
> Serge Knystautas-2 wrote:
> >
> > Thanks for raising this project scope issue since IMHO these are the
> > bigger than technical decisions. If I can restate, currently we
> > support both non-streaming and streaming uses, and have a cu
t
we are talking quite different things here. In particular, I am far from
understanding why they should be mutually exclusive.
Jochen
--
View this message in context:
http://www.nabble.com/-Mime4J--Support-For-Non-Streaming-Inputs-tf4490104.html#a12829975
Sent from the Ja
Am Freitag, den 21.09.2007, 15:30 -0400 schrieb Noel J. Bergman:
> Robert Burrell Donkin wrote:
>
> > it's really about objectives and aims rather than technical designs
>
> > i wonder whether it's worthwhile having what's probably going to be a
> > long technical discussion about a design for a
Robert Burrell Donkin wrote:
> it's really about objectives and aims rather than technical designs
> i wonder whether it's worthwhile having what's probably going to be a
> long technical discussion about a design for a unified parser for both
> streams and non-streams. if no one else really feel
On 9/20/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> i'd like to gauge opinions about whether anyone else feels strongly
> about supporting non-streaming inputs for MimeTokenStream. i've been
> keeping this in mind whilst reviewing jochen's patches but this has
> lead to conflicts about t
On 9/21/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin wrote:
> > Jochen Wiedmann wrote:
> > > robert burrell donkin-2 wrote:
> > > > i'd like to gauge opinions about whether anyone else feels strongly
> > > > about supporting non-streaming inputs for MimeTokenStream. i've b
Hi,
I don't think we need to support non-streaming solutions in mime4j.. But
that's only my "idea"..
bye
Norman
Am Donnerstag, den 20.09.2007, 21:53 +0100 schrieb Robert Burrell
Donkin:
> i'd like to gauge opinions about whether anyone else feels strongly
> about supporting non-streaming inputs
Robert Burrell Donkin wrote:
> Jochen Wiedmann wrote:
> > robert burrell donkin-2 wrote:
> > > i'd like to gauge opinions about whether anyone else feels strongly
> > > about supporting non-streaming inputs for MimeTokenStream. i've been
> > > keeping this in mind whilst reviewing jochen's patches
On 9/20/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>
>
>
> robert burrell donkin-2 wrote:
> >
> > i'd like to gauge opinions about whether anyone else feels strongly
> > about supporting non-streaming inputs for MimeTokenStream. i've been
> > keeping this in mind whilst reviewing jochen's patch
g (keep in mind: This patch is *not* the issue in MIME4J-30)
was developed specifically with java.nio in mind. However, my patch is not
even proposed. Why do we discuss it *before* I post my proposal?
Jochen
--
View this message in context:
http://www.nabble.com/-Mime4J--Support-For-Non-Streaming-In
i'd like to gauge opinions about whether anyone else feels strongly
about supporting non-streaming inputs for MimeTokenStream. i've been
keeping this in mind whilst reviewing jochen's patches but this has
lead to conflicts about the design
(https://issues.apache.org/jira/browse/MIME4J-30). the pric
33 matches
Mail list logo
