I don't have any problem with this solution. It is superior to using a
forward proxy which uploads the entire file then reports progress to
the final server (this was the original model proposed in this thread,
by example).
In fact, I pointed out that the server thread is a proxy, handling
upload prior to allocating a conn thread. If you could peek into this
process, you get feedback.
But this is extremely inefficient. All of these solutions require a
specialized client, even it it seems somewhat transparent to the end
user. So I have pointed out several times that the best solution is a
client side solution which tracks upload progress by knowing the total
file size and the amount of bytes sent.
This really only make sense when the client is somewhat smaller than
the typical upload. Also, downloads are usually faster than uploads,
so the specialized client looks more attractive. the only critical
factor is ease of installation of the client.
Given the size of a tcl client, about 2 meg, any website with a
typical upload of 3+ megs would benefit from an easy to install and
use specialized client. My guess is that the javascript, flash and
java clients could be smaller, but would vary more than a simple tcl
client, which would work unchanged at the script level.
tom jackson
On Mon, Jan 18, 2010 at 12:51 PM, Jim Davidson <jgdavid...@mac.com> wrote:
> Hi,
>
> I think we were talking about this about a month ago. I updated the source
> to enable upload-progress checking with a combination of ns_register_filter
> and nsv -- there's an example at the latest ns_register_filter man page
> (pasted below). This may work for you although it would require compiling
> from latest sources. It assumes you have some javascript thinger that makes
> repeated calls to check the status of the upload in progress on another
> thread.
>
> -Jim
>
>
>
>
>
> EXAMPLE
> The following example uses a read filter to update status of
> a large HTTP POST to the
> /upload/key url where key is some client-specified unique value.
> While the upload is in
> progress, it can be monitored with repeated GET requests to the
> /status/key url with the same
> key:
>
> #
> # Register procs to receive uploads and check status
> # mainted in an nsv array.
> #
>
> ns_register_proc POST /upload upload.post
> ns_register_proc GET /status upload.status
>
> proc upload.status {} {
> set key [ns_conn urlv 1]
> if {[catch {set status [nsv_get status $key]}]} {
> set status "unknown"
> }
> ns_return 200 text/plain $status
> }
>
> proc upload.post {} {
> set key [ns_conn urlv 1]
> nsv_unset status $key
> # ... do something with content ...
> ns_return 200 text/plain received
> }
>
> #
> # Register a read filter ot update status
> #
>
> ns_register_filter read POST /upload/* upload.update
>
> proc upload.update {why} {
> set key [ns_conn urlv 1]
> set expected [ns_conn contentlength]
> set received [ns_conn contentavail]
> set status [list $expected $received]
> nsv_set status $key $status
> return filter_ok
> }
>
>
>
>
>
> On Jan 18, 2010, at 2:39 AM, John Buckman wrote:
>
>>> On 11/24/09 5:13 PM, John Buckman wrote:
>>>> Is there any access (in C or Tcl) to an upload-in-progress in aolserver?
>>>
>>> It'd be nice if we extended ns_info with [ns_info driver ...] that could
>>> give you connection-level info. from the driver thread. In its simplest
>>> form, all we need is to expose the total bytes read/written on a socket
>>> from the driver thread. Bytes read of the POST request's body and the
>>> anticipated Content-Length enables us to compute a rough "progress" -
>>> using the unique URL bit gives us an opaque handle to identify which
>>> connection we're interested in.
>>
>> I've learned a few things by deploying a large-file-upload feature on
>> aolserver:
>>
>> 1) IE times out on large file uploads over DSL, as does Chrome and Safari.
>> Only Firefox seems to have a long enough timeout to enable 600mb file
>> uploads over DSL.
>>
>> 2) All the other file upload sites use a client-side widget to upload a file
>> in parts, not using the browser's upload feature at all. Then, they have a
>> thin server-side program which accepts small chunks of the file upload at a
>> time. Once the widget decides the entire file has been sent, it submits to a
>> new web page, which then collects all the small file chunks.
>>
>> So... instead of working on an upload-in-progress feature, it would make
>> sense instead to have a client-side widget (javascript/flash/java) that
>> sends file upload chunks to a server-side tcl script, and then have a
>> "harvester" tcl script once the widget says the file upload is complete.
>>
>> -john
>>
>>
>> --
>> AOLserver - http://www.aolserver.com/
>>
>> To Remove yourself from this list, simply send an email to
>> <lists...@listserv.aol.com> 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
> <lists...@listserv.aol.com> 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
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
