Kohsuke,
Just contentType in Decoder.decode(inputStream, contentType) may not be
sufficient.
for example AttachmentStreamDecoder would need information about other
HTTP header parameters, such as Multipart/Related header parameters,
such as boundary and start. What we need here is something like
ContentType from JavaMail, that can give easy access to the Mime
parameters or the assumption here is that decode gets the compelte
stream that includes the HTTP headers?
-vivek.
Vivek Pandey wrote:
> Kohsuke Kawaguchi wrote:
>
>> Vivek Pandey wrote:
>>
>>> I would thnik so, otherwise we need to create new transport pipe for
>>> every request.
>>
>>
>>
>> They already have to manage multiple pipelines anyway, so I don't
>> think it's too much trouble for them to manage multiple
>> encoders/decoders.
>>
>> And I thought it does allow encoder/decoder to reuse some of the most
>> costly objects.
>>
> Yep. Thats right.
>
>> Besides, some transport are single-threaded (such as an e-mail
>> transport based on POP3), so I think it makes a good design sense to
>> make them non-reentrant.
>>
> I think this design choice is more driven because of some expensive
> objects. I wonder with the pipes, encoders/decoders being
> non-reentrant how many of such instances will be there, for example
> if client is invoking lots of thread!
>
>> I think what we need is a clone method on pipe, encoder, and decoder,
>> so that whoever invokes the pipe can clone it if necessary.
>>
> ok.
>
> -vivek.
>
--
Vivek Pandey
Web Services Standards and Technologies
Sun Microsystems Inc.