commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Dalquist <edalqu...@unicon.net>
Subject Re: [codec-multipart] Who's In Charge
Date Thu, 01 Jul 2004 21:09:48 GMT
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 could be quite large and forcing the user to store it 
in memory wouldn't be very nice. I'm doing some more re-working on the 
codec-multipart code so it supports streams as well. I tried emailing 
Mark directly, I'll see what he says about the whole thing when he gets 
back to me. Once I get a better re-work of the code done what should I 
do? I'm very interesting in adding this code to the codec project.

-Eric Dalquist



Gary Gregory wrote:

>>Thinking more about the structure of the Encoder and Decoder
>>    
>>
>interfaces
>
>I've never been crazy about these various interfaces. In our company's
>product at least, we've never needed pluggable impls. Some of the Codecs
>are so different that it does not look like being able to replace one
>with another makes sense. OTOH, having interfaces gives you the option
>of using and creating pluggable guys, which is fine. 
>
>All of this to say that I would not initially worry that much about
>fitting a new package in these interfaces unless you believe that
>"plugability" is a requirement.
>
>  
>
>>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.
>
>Perhaps now is the time to revive these discussions.
>
>Gary
>
>  
>
>>-----Original Message-----
>>From: Eric Dalquist [mailto:edalquist@unicon.net]
>>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
>>    
>>
>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 basic idea is you have a Part interface. From that there is a
>>StringPart and a FilePart.
>>The MultipartEncoder would need to take an array of Parts and encode
>>them into a multipart message. One big difference is because of the
>>possible size of a multipart message the preferred way to get the
>>    
>>
>output
>  
>
>>of the encoder would be via an InputStream. This would allow the
>>    
>>
>message
>  
>
>>to be constructed on the fly and written to the caller. The caller
>>    
>>
>could
>  
>
>>then write the data directly out to whatever needs it, keeping memory
>>usage down to a minimum. I'm not sure how this method of encoding
>>    
>>
>would
>  
>
>>be handled by the current Encoder interface.
>>Also for decoding the opposite would be true. The decoder would need
>>    
>>
>to
>  
>
>>read it's data from an InputStream and return an array of parts. The
>>decoder would provide the option for file data to be written to a user
>>specified temp directory so the only data stored in the Part objects
>>would be a reference to the temp file via a File object.
>>
>>Let me know what you think of this.
>>
>>-Eric Dalquist
>>
>>Gary Gregory wrote:
>>
>>    
>>
>>>Hello,
>>>
>>>The only person I see in codec-multipart/project.xml is:
>>>
>>>       <developer>
>>>           <name>Mark Diggory</name>
>>>           <id>mdiggory</id>
>>>           <email>mdiggory at apache.org</email>
>>>       </developer>
>>>
>>>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 volunteers are
>>>welcome.
>>>
>>>Perhaps you could discuss on this list the pros and cons for a
>>>      
>>>
>multipart
>  
>
>>>addition to the next feature release of codec. A proposal type of
>>>      
>>>
>thing
>  
>
>>>;-)
>>>
>>>Gary
>>>
>>>
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Eric Dalquist [mailto:edalquist@unicon.net]
>>>>Sent: Thursday, July 01, 2004 10:29
>>>>To: Jakarta Commons Developers List
>>>>Subject: [codec-multipart] Who's In Charge
>>>>
>>>>I'm wondering who I should talk about about the codex-multipart
>>>>
>>>>
>>>>        
>>>>
>>>project
>>>
>>>
>>>      
>>>
>>>>in the commons sandbox. I have some changes that I really would like
>>>>
>>>>
>>>>        
>>>>
>>>to
>>>
>>>
>>>      
>>>
>>>>discuss with the maintainer.
>>>>
>>>>-Eric Dalquist
>>>>
>>>>Eric Dalquist wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>I needed to find a way to reconstruct a submitted multipart form
>>>>>
>>>>>
>>>>>          
>>>>>
>>>from
>>>
>>>
>>>      
>>>
>>>>>the files and parameters stored in temp locations. I was directed
>>>>>          
>>>>>
>to
>  
>
>>>>>the codec-multipart code and found it did part of what I wanted. I
>>>>>
>>>>>
>>>>>          
>>>>>
>>>did
>>>
>>>
>>>      
>>>
>>>>>make some rather extensive changes  to the way it functions to make
>>>>>
>>>>>
>>>>>          
>>>>>
>>>it
>>>
>>>
>>>      
>>>
>>>>>fit my application.
>>>>>
>>>>>The big issues I had were with the inability to control the
>>>>>          
>>>>>
>boundary
>  
>
>>>>>and the fact that by using static methods for a majority of the
>>>>>          
>>>>>
>work
>  
>
>>>>>the code was not threadsafe. I would be more that willing to submit
>>>>>
>>>>>
>>>>>          
>>>>>
>>>my
>>>
>>>
>>>      
>>>
>>>>>changes for review and make modifications to the architecture as
>>>>>needed to get the code accepted into the codec-multipart project.
>>>>>Please let me know two who or where I should upload the modified
>>>>>
>>>>>
>>>>>          
>>>>>
>>>source.
>>>
>>>
>>>      
>>>
>>>>>-Eric Dalquist
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>---------------------------------------------------------------------
>>>
>>>
>>>      
>>>
>>>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail:
>>>>>          
>>>>>
>commons-dev-help@jakarta.apache.org
>  
>
>>>>>
>>>>>          
>>>>>
>>>---------------------------------------------------------------------
>>>      
>>>
>>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>        
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>

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