[Seaside] support for streamed files with Zinc adaptor?
philippe.marschall at gmail.com
Wed Jun 20 06:50:48 UTC 2012
On Wed, Jun 20, 2012 at 7:41 AM, Philippe Marschall
<philippe.marschall at gmail.com> wrote:
> On Tue, Jun 19, 2012 at 10:06 PM, Sven Van Caekenberghe <sven at beta9.be> wrote:
>> Hey Philippe,
>> On 19 Jun 2012, at 20:15, Philippe Marschall wrote:
>>> On Tue, Jun 19, 2012 at 4:12 PM, Sven Van Caekenberghe <sven at beta9.be> wrote:
>>>> Hi Esteban,
>>>> On 19 Jun 2012, at 15:31, Esteban Lorenzano wrote:
>>>>> Hi Sven el all
>>>>> I'm using Zinc-Adaptor and I need to upload files. I remember Comanche adaptor had support for streamed files (they were derived to a temporary file instead load everything in the image).
>>>>> While I could configure nginx or apache to do that, I would like to be able to do it using plain Seaside too.
>>>>> It is possible with Zinc-Adaptor?
>>>> I am (still) confused as to what exactly is expected of a 'streaming' Seaside adaptor.
>>> There are two different issues, file upload streaming and response streaming.
>>> What I believe is wanted here is file upload streaming. The idea is
>>> that instead of loading the whole contents of a file upload into
>>> memory (and copying it several times along the way) you stream the
>>> contents into a file on disk and just get a "handle" to the file.
>>> Dealing with multipart mime makes this a bit tricky, you don't want to
>>> do this for normal upload fields. So you need to hook into your mime
>>> parser. It's basically the same as mod_upload does . Looking for
>>> references to WATemporaryFile in an up to date Seaside image 
>>> should get you started. Note that the Comanche implementation relies
>>> on the fact that the request is dispatched after the headers are
>>> parsed before the body is fully parsed.
>> Thanks for the excellent, to the point explanation.
>> I browsed the code and found what I was looking for.
>> This won't be easy as it depends on, first a streaming multipart parser (the one currently used is based on your AJP parser that works on a byte array, do you have another one ?),
> No, as AJP works only behind a front end server you'd probably do this
> is with a module there instead of in the Smalltalk image. So I don't
> have a need for it.
>> second in Zn currently only generic byte streams can be seen as streaming entities, not interpreted/parsed ones like multipart, I'll have to think about that.
> If you encode the multipart boundary with the request encoding you
> should be able to do the parsing on byte streams, in theory, I haven't
> tested it.
However, on second thought you still need to do header decoding.
More information about the seaside