commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [codec-multipart] Who's In Charge
Date Fri, 02 Jul 2004 00:53:34 GMT
Sorry guys, I wasn't listening. Let me review the thread and catch up to you

-Mark

Gary Gregory wrote:

>The best place to track this for now is Bugzilla I think. Create a
>ticket and attach your code as a CVS diff patch file.
>
>Gary
>
>  
>
>>-----Original Message-----
>>From: Eric Dalquist [mailto:edalquist@unicon.net]
>>Sent: Thursday, July 01, 2004 14:10
>>To: Jakarta Commons Developers List
>>Subject: Re: [codec-multipart] Who's In Charge
>>
>>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
>>    
>>
>
>
>---------------------------------------------------------------------
>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