On Fri, 9 Jan 2004, Noel J. Bergman wrote:
> Can someone please explain the context for this discussion? I was not
Sorry, my fault. This started from a thread on commons-user entitled:
[net] Why use Net for SMTP?
where the question was asked: Given that JavaMail is standard and does the
job, why would one choose to use the SMTP facilities in Commons Net? This
led to a comment that, to make Commons Net useful in this respect, it may
need a higher level API. That, in turn, might involve multipart MIME
handling.
The topic of multipart handling in HttpClient then came up, which led me
back to thinking about the multipart handling in FileUpload, and how it
might be rather nice if we pulled all of this multipart handling out into
a common place, hence this fork of the original thread.
>From pulling multipart code out into a Commons Multipart component, we
have now come to talking about creating a shared MIME component, perhaps
within Commons Codec, which I think is a fine idea.
> entirely paying attention, and it seems to have come from elsewhere, but
> these items DEFINITELY caught my attention:
>
> > I think I could also offer my +0.5 in terms of contributing MIME
> > specific code.
>
> > allow me to suggest MIME related classes be folded into Commons-Codec
> > instead of being spawned as a separate project. MIME classes would
> > inevitably require several codecs (Base64 and quote-printable encoding
> > at the very least) to be of any use in applications targeting
> > international audience, primarily due to the fact that per definition
> > non-ASCII characters in MIME headers must be escaped.
>
> > I really like the model for handling multipart content currently
> > maintained in HttpClients MultipartPost method. For the most part, your
> > going to either have content in memory or in a file on the filesystem,
> > generically wrapping any "Part" including references to a file in the
> > filesystem allows one not to have to put it into memory and still
> > process it into the Writer/Stream without the user really needing to
> > manage it.
>
> > If there is a consideration to work on the SMTP implementation. This is
> > an excellent approach to consider.
>
> One of the issues we have in James is the fact that JavaMail wants to do
> everything in memory, so we have limited abilities to parse and manipulate
> large messages. I have a project item on my plate to work on addressing
> that issue, so any discussion of code for parsing and processing MIME for
> SMTP messages has my immediate attention. I had started looking (NIH is a
> place in DC, not an attitude for a programmer) elsewhere for code (Java or
> C/C++), but had not yet found what I need.
Yah, I am, unfortunately, familiar with the limitations of JavaMail in
this respect. ;-)
If we're going to put this MIME thingy together, it would seem that the
issues being faced by James would provide a nice set of design criteria to
add to the puzzle. A robust MIME library that would satisfy the needs of
James, HttpClient, FileUpload, and possibly others, would be awesome.
--
Martin Cooper
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
