[codec] multipart encoders/decoders

["Mark R. Diggory" <md...@latte.harvard.edu>]

If we want eventually add multipart encoders/decoders to codec, should we:

(1) reopen the codec sandbox,
(2) start a new sandbox project, or
(3) work directly in the codec project?

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.
>>
> 

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu

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

RE: [codec] multipart encoders/decoders

[Brett Henderson <ja...@bretth.com>]

> 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.

I have no problems with this but so far I haven't seen anything
like this that doesn't sub-class InputStream and OutputStream.
Sub-classing InputStream and OutputStream is problematic because
it forces you to code algorithms around IOStream semantics
(InputStream coding is not simple, especially available() method)
and it forces you to make the encoder sub-class OutputStream and
the decoder sub-class InputStream unless you write an
implementation for each stream type.
Providing a single InputStream implementation that can use an
underlying codec engine simplifies development and testing
of new algorithms considerably and removes the distinction between
input and output streams.

> 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'm often guilty of over designing things, hey it's fun :-)
Would it help if I didn't call my classes a "framework"?
It's no more than a few common interfaces and some implementation
codecs.  There are no factories, or service providers, or other
abstractions complicating things.
It really isn't much different to the existing codec interfaces
except that they are written to support streaming and separate
input and output interfaces.
I really think there's a need for all streamable codecs to follow
common interfaces.  Perhaps InputStream and OutputStream are
sufficient but I think there's a better way.


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

Re: [codec] multipart encoders/decoders

[Tim O'Brien <to...@discursive.com>]

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