commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim O'Brien <tobr...@discursive.com>
Subject Re: [codec] multipart encoders/decoders
Date Mon, 12 Jan 2004 19:06:28 GMT
On Mon, 12 Jan 2004, Mark R. Diggory wrote:

> (3) work directly in the codec project?

Mark, please feel free to add this to the codec HEAD in commons proper.  

Here are a few good rules of thumb:

1. Commons exists as an effort to encourage code reuse.  The Streamable 
framework presented was interesting, but I'd like us to find an existing 
streamable Base64 implementation inside of the ASF codebase.

2. Once a product is in commons proper, forget the sandbox.  

3. No need to expressly focus on a framework (at all).  Codec is FIRSTLY a 
functional beast, even if the solution is inelegant.  If there is an 
existing streamable Base64 in ASF, I'd recommend copying it outright and 
placing in the codec package.  Over time, it can move towards a unified 
streamable framework.

> 
> I currently have extracted the multipart post encoding from the 
> HttpClient multipart post code and am working on an initial framework to 
> support its addition to codec. I would like to get this into the sandbox 
> soon but want to be flexible o others needs, if there is interest in 
> also working on Streamable Codecs, my code would benefit from Streamable 
> encoder/decoder interfaces, thus we should probably work on that code in 
> the same place.
> 
> -Mark
> 
> Mark R. Diggory wrote:
> 
> > Hmmm, thats a Hot Potato, I suspect we won't be using it (at least 
> > initially). ;-)
> > 
> > Maybe to focus in the initial deliverable we would require:
> > 
> >> 2.) Multipart Mime Codecs
> >>
> >> Maintaining Multipart Encoding in the various multipart mimetypes. 
> > 
> > 
> > Multipart Types (mostly email)            
> > Messages with multiple parts            multipart/mixed
> > Messages with multiple, alternative parts     multipart/alternative
> > Message with multiple, related parts         multipart/related
> > Multiple parts are digests            multipart/digest
> > For reporting of email status (admin.)         multipart/report
> > Order of parts does not matter            multipart/parallel
> > Macintosh file data                multipart/appledouble
> > Aggregate messages; descriptor as header     multipart/header-set
> > Container for voice-mail             multipart/voice-message
> > HTML FORM data (see Ch. 9 and App. B)        multipart/form-data
> > Infinite multiparts - See Chapter 9 (Netscape) multipart/x-mixed-replace
> > 
> > 
> > 1.) Which do we want to support?
> > 
> > 2.) How might we write an extensible (and nestable) API to encode/decode 
> > various multiparts elegantly?
> > 
> > Currently, HttpClient maintains this efficiently in the form of "Parts"
> > 
> > MultipartPostMethod.addPart(Part part);
> > 
> > Part
> >    ---StringPart
> >    ---FilePart
> > 
> > All parts have a Part.send(OutputStream out) method responsible for 
> > encoding and streaming the Parts contents to the MultipartPostMethod.
> > 
> > 1.) This means that Parts are kept in their native Format/State/Object 
> > until they are processed into the Steam.
> > 
> > 2.) Currently in HttpClient, Parts also generate the "Multipart" 
> > portions of the encoding (ie boundaries etc). Ideally, the "processor" 
> > of the Part should probably be more responsible for this, with the Part 
> > just generating a Stream of its content and the "codec" responsible for 
> > the boundaries/encoding etc. This way, no matter the codec 
> > (multipart/related, multipart/mixed, etc) the user is still working with 
> > he same "Parts" and the only difference is the "codec"/"factory"). This 
> > is similar in nature to the idea of service providers and JNDI. Your 
> > still working with "Context/Attributes/SearchResults" no matter what 
> > Service provider your using (DNS, LDAP, FS).
> > 
> > 3.) This is why I initially though JAF would be a responsible choice, 
> > delivering Parts that also had "mimetypes" associated with them, the 
> > codec could then simply use the mimetype to determine the appropriate 
> > encoding for that specific multipart codec.
> > 
> > -Mark
> > 
> > Serge Knystautas wrote:
> > 
> >> Noel J. Bergman wrote:
> >>
> >>> Mark R. Diggory asked:
> >>>
> >>>> Shouldn't [mime] be dependent on JAF?
> >>>
> >>>
> >>>
> >>> Why?
> >>
> >>
> >>
> >> Looks like others already stated this, but here's my why/why not:
> >>
> >> why: it's an established API that doesn't have anything to do with 
> >> MIME handling.  JAF handles creating Java objects from streams.  (This 
> >> was listed as one of the tasks for this initiative, and I don't think 
> >> it really belongs).
> >>
> >> why not: it's really really painful to use.  It has a a decent idea of 
> >> a data handler, but it's just way to complicated
> >>
> >> I would prefer JAF and otherwise object instantiation from streams be 
> >> unrelated to mime.  The reason it current works this way is so you can 
> >> "nest" MimeMultipart objects, but I think there's a better way to wrap 
> >> this.
> >>
> > 
> 
> 

-- 
----------------------
Tim O'Brien
Evanston, IL
(847) 863-7045
tobrien@discursive.com



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message