Gustaf,

Oops, accidentally hit send.

I just started work on an event driven http client (called htclient).
It can monitor downloads just by using a variable trace. I haven't
reversed the idea for uploads yet, but it would be easy. Not so easy
is guessing the length of the encoded file prior to sending. Seems
like a better solution for large file uploads would be to do the
upload as binary data instead of multi-part and get direct local
monitoring and the ability to cancel, and/or restart a failed upload.

For clients who have tcl/tk installed, it would be easy to
auto-generate a tcl script to handle one or several uploads.

tom jackson

On Wed, Nov 25, 2009 at 9:13 AM, Tom Jackson <[email protected]> wrote:
> Gustaf,
>
> I've seen these working, although I'm never sure where exactly the
> magic happens.  It looks like the ngix idea is to work as a proxy:
>
> "It works because Nginx acts as an accelerator of an upstream server,
> storing uploaded POST content on disk, before transmitting it to the
> upstream server. Each individual POST upload request should contain a
> progress unique identifier. "
>
> I wonder if the progress is from you to ngix, or from ngix to the final 
> server.
>
> On Wed, Nov 25, 2009 at 4:07 AM, Gustaf Neumann <[email protected]> wrote:
>> Tom Jackson schrieb:
>>>
>>> John,
>>>
>>> I'm just going to venture a guess. I hope that Jim D. or someone else
>>> more familiar with the internals will set me straight.
>>>
>>> The problem with upload progress monitoring is that uploads are
>>> finished before a conn thread is allocated.
>>>
>>> Uploads are done in the driver thread, or a worker thread before the
>>> conn thread is given control.
>>>
>>
>> Tom,
>>
>> the typical meachnism for upload progress bars is that separate (ajax)
>> queries
>> are used to query the state of an running upload, which is identified by
>> some
>> unique ID (e.g. X-Progress-ID in
>> http://wiki.nginx.org/NginxHttpUploadProgressModule,
>> or some other heuristics. e.g. based on URL and peer addr).
>> So, one needs just a thread-safe introspection meachnism, which
>> checks in the spooler the state (such as "ns_upload_stats"
>> in naviserver) and returns it back. The spooler hast just to update
>> these statistics when it recieves data.
>>
>> -gustaf neumann
>>
>>
>> --
>> AOLserver - http://www.aolserver.com/
>>
>> To Remove yourself from this list, simply send an email to
>> <[email protected]> with the
>> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
>> field of your email blank.
>>
>


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
<[email protected]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to