Re: [Catalyst] Progress bar
I meant to follow this up, a long time ago. Just to say: I ported my app to use an HTML5-based upload progress thingy. I wrote it from scratch, it's made of awesome, haven't looked back. (Except to the poor suckers on Internet Explorer who, despite finally getting to version 8 or 9, still can't use it!) On 24 October 2012 15:33, Toby Corkindale wrote: > I was just investigating why the upload progress bar was broken on one > of my apps.. came here to make a post and discovered this thread. > Well, at least that's the first question answered! > > Given the caveats around Starman and WebKit browsers, are there any > other suggestions for how to do upload progress indicators? > Is this something we can do via HTML5 neater? Are there any > open-source Flash implementations? > > Cheers, > Toby > > On 22 October 2012 09:42, Bill Moseley wrote: >> >> On Sat, Oct 20, 2012 at 1:51 PM, Tomas Doran wrote: >>> >>> And UploadProgress is shipped, should be available once it's reindexed >>> (permissions cock up), which should be shortly :) >> >> >> So, when running under Starman the uploads are buffered before chunked to >> Catalyst, which means the progress bar data isn't updated until the upload >> has completed. This renders the upload progress bar pretty useless with >> Starman. >> >> The progress bar works fine running the app under mod_perl. >> >> I suppose using something like Nginx or Perlbal in front of the app would >> work (because those do cache uploads but also provide a hook for reading >> upload progress). But, we already have hardware load balancers in front of >> the app, so don't really need an extra proxy in front of every web server. >> >> Any other options? Using a upload/request caching proxy is probably THE >> correct answer since don't really want to tie up the app with slow uploads. >> >> I guess I should test, but I wonder if there's a limit on what Starman will >> buffer -- I assume it's buffering in memory. >> >> >> >> >> -- >> Bill Moseley >> mose...@hank.org >> >> ___ >> List: Catalyst@lists.scsys.co.uk >> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >> Dev site: http://dev.catalyst.perl.org/ >> > > > > -- > Turning and turning in the widening gyre > The falcon cannot hear the falconer > Things fall apart; the center cannot hold > Mere anarchy is loosed upon the world -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On Thu, Oct 25, 2012 at 5:29 AM, Aaron Trevena wrote: > On 24 October 2012 17:59, Bill Moseley wrote: > > PerlBal (as in this old post: > > http://lists.danga.com/pipermail/perlbal/2005-November/000138.html ) > can do > > this as well. > > > > I wonder about the topology. We used to run with Perlbal (and heartbeat > > and IP failover) in front of a pool of web servers. We now run with > > hardware load balancers in front of a pool of web servers. > > > > The load balancer does make it easy to adjust the pool -- as well as > > gracefully handle a web server dropping out of the pool. I don't want > to > > add yet another set of servers for an extra proxy layer. > > > > So, I'm currently thinking of running Nginx on each web server. > (Keep-alive > > between the load balancer and Nginx, and no keep-alive between Nginx and > > Catalyst with maybe Starman.) > > Um... how is adding nginx instead of perlbal not "adding yet another > set of servers"? > I'm talking hardware. I'd rather not add another set of servers between the load balancer and the web pool. It's just more to manage and monitor and one more place to fail. We used to run Perlbal like that when we had less capable load balancers. If I put Nginx/Perlbal on each web server it simplifies the architecture. No need to run redundant Perlbal/Nginx with heartbeat and failover on a separate set of servers in each data center. > What features of nginx are you looking to use vs say perlbal - depends > on how you'd use it and what for, and how easily either would acheive > your goals easily - perlbal *could* have a short/shallower learning > curve, or nginix may be drop-in job that just works without any > customisation or special extensions > Obviously, I'm looking for working progress bar, but also upload buffering so the web app processes are not tied up waiting on client uploads. Of course, scaling extra web processes is pretty easy which is why we haven't worried too much about buffering uploads. Haven't had the need to reproxy. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On 24 October 2012 17:59, Bill Moseley wrote: > PerlBal (as in this old post: > http://lists.danga.com/pipermail/perlbal/2005-November/000138.html ) can do > this as well. > > I wonder about the topology. We used to run with Perlbal (and heartbeat > and IP failover) in front of a pool of web servers. We now run with > hardware load balancers in front of a pool of web servers. > > The load balancer does make it easy to adjust the pool -- as well as > gracefully handle a web server dropping out of the pool. I don't want to > add yet another set of servers for an extra proxy layer. > > So, I'm currently thinking of running Nginx on each web server. (Keep-alive > between the load balancer and Nginx, and no keep-alive between Nginx and > Catalyst with maybe Starman.) Um... how is adding nginx instead of perlbal not "adding yet another set of servers"? Perlbal does more than simple pooling and proxying too - it's very useful indeed for rewriting urls and stuff like reproxying, etc that h/ware load balancers don't support > Anyone see why this might be a bad (or good) approach? What features of nginx are you looking to use vs say perlbal - depends on how you'd use it and what for, and how easily either would acheive your goals easily - perlbal *could* have a short/shallower learning curve, or nginix may be drop-in job that just works without any customisation or special extensions A. -- Aaron J Trevena, BSc Hons http://www.aarontrevena.co.uk LAMP System Integration, Development and Consulting ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On Wed, Oct 24, 2012 at 9:59 AM, Bill Moseley wrote: > > > On Wed, Oct 24, 2012 at 5:44 AM, Lorn wrote: >> >> I'm not following the thread but, did you guys know about >> http://wiki.nginx.org/HttpUploadProgressModule. ? > > > PerlBal (as in this old post: > http://lists.danga.com/pipermail/perlbal/2005-November/000138.html ) can do > this as well. I can vouch for the scalability of the Perlbal upload tracker. I used it on taperfriendlymusic.org in front of a slashcode based mod_perl app in 2006, and one box was able to handle 50 megabits of uploads with around 10% cpu usage. > > I wonder about the topology. We used to run with Perlbal (and heartbeat > and IP failover) in front of a pool of web servers. We now run with > hardware load balancers in front of a pool of web servers. > > The load balancer does make it easy to adjust the pool -- as well as > gracefully handle a web server dropping out of the pool. I don't want to > add yet another set of servers for an extra proxy layer. > > So, I'm currently thinking of running Nginx on each web server. (Keep-alive > between the load balancer and Nginx, and no keep-alive between Nginx and > Catalyst with maybe Starman.) > > Anyone see why this might be a bad (or good) approach? > > -- > Bill Moseley > mose...@hank.org > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On Wed, Oct 24, 2012 at 5:44 AM, Lorn wrote: > I'm not following the thread but, did you guys know about > http://wiki.nginx.org/HttpUploadProgressModule. ? > PerlBal (as in this old post: http://lists.danga.com/pipermail/perlbal/2005-November/000138.html ) can do this as well. I wonder about the topology. We used to run with Perlbal (and heartbeat and IP failover) in front of a pool of web servers. We now run with hardware load balancers in front of a pool of web servers. The load balancer does make it easy to adjust the pool -- as well as gracefully handle a web server dropping out of the pool. I don't want to add yet another set of servers for an extra proxy layer. So, I'm currently thinking of running Nginx on each web server. (Keep-alive between the load balancer and Nginx, and no keep-alive between Nginx and Catalyst with maybe Starman.) Anyone see why this might be a bad (or good) approach? -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Progress bar
Or a plethora of other methods using PHP/Perl/JQuery/Flash/HTML5 https://github.com/blueimp/jQuery-File-Upload http://www.uploadify.com/ http://sourceforge.net/projects/uber-uploader/ From: Lorn [mailto:l...@lornlab.org] Sent: 24 October 2012 13:45 To: The elegant MVC web framework Subject: Re: [Catalyst] Progress bar I'm not following the thread but, did you guys know about http://wiki.nginx.org/HttpUploadProgressModule. ? They work together with upload module, and dont "overload" your backend with upload files, nginx handle that and just pass the file path to the backend. -- Lorn On Wednesday, 24 de October de 2012 at 02:33, Toby Corkindale wrote: I was just investigating why the upload progress bar was broken on one of my apps.. came here to make a post and discovered this thread. Well, at least that's the first question answered! Given the caveats around Starman and WebKit browsers, are there any other suggestions for how to do upload progress indicators? Is this something we can do via HTML5 neater? Are there any open-source Flash implementations? Cheers, Toby On 22 October 2012 09:42, Bill Moseley mailto:mose...@hank.org>> wrote: On Sat, Oct 20, 2012 at 1:51 PM, Tomas Doran mailto:bobtf...@bobtfish.net>> wrote: And UploadProgress is shipped, should be available once it's reindexed (permissions cock up), which should be shortly :) So, when running under Starman the uploads are buffered before chunked to Catalyst, which means the progress bar data isn't updated until the upload has completed. This renders the upload progress bar pretty useless with Starman. The progress bar works fine running the app under mod_perl. I suppose using something like Nginx or Perlbal in front of the app would work (because those do cache uploads but also provide a hook for reading upload progress). But, we already have hardware load balancers in front of the app, so don't really need an extra proxy in front of every web server. Any other options? Using a upload/request caching proxy is probably THE correct answer since don't really want to tie up the app with slow uploads. I guess I should test, but I wonder if there's a limit on what Starman will buffer -- I assume it's buffering in memory. -- Bill Moseley mose...@hank.org<mailto:mose...@hank.org> ___ List: Catalyst@lists.scsys.co.uk<mailto:Catalyst@lists.scsys.co.uk> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk<mailto:Catalyst@lists.scsys.co.uk> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ This Email and any attachments contain confidential information and is intended solely for the individual to whom it is addressed. If this Email has been misdirected, please notify the author as soon as possible. If you are not the intended recipient you must not disclose, distribute, copy, print or rely on any of the information contained, and all copies must be deleted immediately. Whilst we take reasonable steps to try to identify any software viruses, any attachments to this e-mail may nevertheless contain viruses, which our anti-virus software has failed to identify. You should therefore carry out your own anti-virus checks before opening any documents. HomeLoan Partnership will not accept any liability for damage caused by computer viruses emanating from any attachment or other document supplied with this e-mail. HomeLoan Partnership reserves the right to monitor and archive all e-mail communications through its network. No representative or employee of HomeLoan Partnership has the authority to enter into any contract on behalf of HomeLoan Partnership by email. HomeLoan Partnership is a trading name of H L Partnership Limited, registered in England and Wales with Registration Number 5011722. Registered office: 26-34 Old Street, London, EC1V 9QQ. H L Partnership Limited is authorised and regulated by the Financial Services Authority. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
I'm not following the thread but, did you guys know about http://wiki.nginx.org/HttpUploadProgressModule. ? They work together with upload module, and dont "overload" your backend with upload files, nginx handle that and just pass the file path to the backend. -- Lorn On Wednesday, 24 de October de 2012 at 02:33, Toby Corkindale wrote: > I was just investigating why the upload progress bar was broken on one > of my apps.. came here to make a post and discovered this thread. > Well, at least that's the first question answered! > > Given the caveats around Starman and WebKit browsers, are there any > other suggestions for how to do upload progress indicators? > Is this something we can do via HTML5 neater? Are there any > open-source Flash implementations? > > Cheers, > Toby > > On 22 October 2012 09:42, Bill Moseley wrote: > > > > On Sat, Oct 20, 2012 at 1:51 PM, Tomas Doran wrote: > > > > > > And UploadProgress is shipped, should be available once it's reindexed > > > (permissions cock up), which should be shortly :) > > > > > > > > > > > So, when running under Starman the uploads are buffered before chunked to > > Catalyst, which means the progress bar data isn't updated until the upload > > has completed. This renders the upload progress bar pretty useless with > > Starman. > > > > The progress bar works fine running the app under mod_perl. > > > > I suppose using something like Nginx or Perlbal in front of the app would > > work (because those do cache uploads but also provide a hook for reading > > upload progress). But, we already have hardware load balancers in front of > > the app, so don't really need an extra proxy in front of every web server. > > > > Any other options? Using a upload/request caching proxy is probably THE > > correct answer since don't really want to tie up the app with slow uploads. > > > > I guess I should test, but I wonder if there's a limit on what Starman will > > buffer -- I assume it's buffering in memory. > > > > > > > > > > -- > > Bill Moseley > > mose...@hank.org > > > > ___ > > List: Catalyst@lists.scsys.co.uk > > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > > Dev site: http://dev.catalyst.perl.org/ > > > > > > > -- > Turning and turning in the widening gyre > The falcon cannot hear the falconer > Things fall apart; the center cannot hold > Mere anarchy is loosed upon the world > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > > ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
I was just investigating why the upload progress bar was broken on one of my apps.. came here to make a post and discovered this thread. Well, at least that's the first question answered! Given the caveats around Starman and WebKit browsers, are there any other suggestions for how to do upload progress indicators? Is this something we can do via HTML5 neater? Are there any open-source Flash implementations? Cheers, Toby On 22 October 2012 09:42, Bill Moseley wrote: > > On Sat, Oct 20, 2012 at 1:51 PM, Tomas Doran wrote: >> >> And UploadProgress is shipped, should be available once it's reindexed >> (permissions cock up), which should be shortly :) > > > So, when running under Starman the uploads are buffered before chunked to > Catalyst, which means the progress bar data isn't updated until the upload > has completed. This renders the upload progress bar pretty useless with > Starman. > > The progress bar works fine running the app under mod_perl. > > I suppose using something like Nginx or Perlbal in front of the app would > work (because those do cache uploads but also provide a hook for reading > upload progress). But, we already have hardware load balancers in front of > the app, so don't really need an extra proxy in front of every web server. > > Any other options? Using a upload/request caching proxy is probably THE > correct answer since don't really want to tie up the app with slow uploads. > > I guess I should test, but I wonder if there's a limit on what Starman will > buffer -- I assume it's buffering in memory. > > > > > -- > Bill Moseley > mose...@hank.org > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On Sat, Oct 20, 2012 at 1:51 PM, Tomas Doran wrote: > And UploadProgress is shipped, should be available once it's reindexed > (permissions cock up), which should be shortly :) > So, when running under Starman the uploads are buffered before chunked to Catalyst, which means the progress bar data isn't updated until the upload has completed. This renders the upload progress bar pretty useless with Starman. The progress bar works fine running the app under mod_perl. I suppose using something like Nginx or Perlbal in front of the app would work (because those do cache uploads but also provide a hook for reading upload progress). But, we already have hardware load balancers in front of the app, so don't really need an extra proxy in front of every web server. Any other options? Using a upload/request caching proxy is probably THE correct answer since don't really want to tie up the app with slow uploads. I guess I should test, but I wonder if there's a limit on what Starman will buffer -- I assume it's buffering in memory. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
And UploadProgress is shipped, should be available once it's reindexed (permissions cock up), which should be shortly :) Cheers t0m On 19 Oct 2012, at 22:51, Tomas Doran wrote: > > On 18 Oct 2012, at 16:14, Bill Moseley wrote: >> How close is this version of Catalyst for a release? Unfortunately, I >> noticed this while preparing for an app release next week. > > About now - there are a couple of other patches, and I have half a tuit spare > :) > > Cheers > t0m > > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On 18 Oct 2012, at 16:14, Bill Moseley wrote: > How close is this version of Catalyst for a release? Unfortunately, I > noticed this while preparing for an app release next week. About now - there are a couple of other patches, and I have half a tuit spare :) Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On Wed, Oct 17, 2012 at 12:34 AM, Tomas Doran wrote: > > Can I get a 'yes this new code works' from someone trying it before we > ship new versions? :) > Yes it works like it used to, now. Thanks. >From what I remember this can't work on Safari and Chrome (Webkit). Need to use the iframe trick on those browsers. https://bugs.webkit.org/show_bug.cgi?id=23933 How close is this version of Catalyst for a release? Unfortunately, I noticed this while preparing for an app release next week. Thanks, -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On 17 Oct 2012, at 15:54, Bill Moseley wrote: > > > On Wed, Oct 17, 2012 at 12:34 AM, Tomas Doran wrote: > > > This needs a Catalyst release first - I was waiting till there were a few > more changes for that, but if it's hurting people now, we could do a new > version with just the tiny changes I made to support this. > > By the way, I wonder if it wouldn't be cleaner to use _build_request instead > of a builder for the args. In this case might have to completely override > _build_request to inject in the cache -- or make the cache "rw" so that it > can be set after _build_request. No, and the explicit reason it's not cleaner is that 'rw' - would that we could change things so that the request object was constructed in it's final immutable form! > Seems like giving the request the app as an attribute would be a bad idea, > but not clear what that is. :) > Too much coupling! App has a request has an app - ARGH. > I've been struggling a bit with hierarchy of classes where I need to pass > child construction params down to child constructors. I've added "parent" > attributes to the child classes, manually passed args (as you are doing > here), and even had separate config objects that I pass around. Haven't > found anything that I'm that fond of. You should inject _just_ the dependencies that the class in question needs, having explicitly broken them out. Passing the app down makes the app a 'god object'. Why would you care? Well, Say you want to persist most session data into the DB, but you're happy with progress bars being in memcache - if you pass the cache explicitly to the request you can do this trivially, if you pass the entire $c or $app down to the request, you cannot do this at all. Hope this helps! Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On Wed, Oct 17, 2012 at 12:34 AM, Tomas Doran wrote: > > > This needs a Catalyst release first - I was waiting till there were a few > more changes for that, but if it's hurting people now, we could do a new > version with just the tiny changes I made to support this. > By the way, I wonder if it wouldn't be cleaner to use _build_request instead of a builder for the args. In this case might have to completely override _build_request to inject in the cache -- or make the cache "rw" so that it can be set after _build_request. Seems like giving the request the app as an attribute would be a bad idea, but not clear what that is. :) I've been struggling a bit with hierarchy of classes where I need to pass child construction params down to child constructors. I've added "parent" attributes to the child classes, manually passed args (as you are doing here), and even had separate config objects that I pass around. Haven't found anything that I'm that fond of. > > Can I get a 'yes this new code works' from someone trying it before we > ship new versions? :) > > Cheers > t0m > > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On Wed, Oct 17, 2012 at 12:34 AM, Tomas Doran wrote: > > On 17 Oct 2012, at 07:13, Dimitar Petrov wrote: > > > Hey Bill, > > > > I think t0m fixed that a week ago in trunk and it should be working. You > might want to check the trunk of the Catalyst and the Plugin and to see if > it works for you and probably ask t0m to upload new version on CPAN. > > This needs a Catalyst release first - I was waiting till there were a few > more changes for that, but if it's hurting people now, we could do a new > version with just the tiny changes I made to support this. > > Can I get a 'yes this new code works' from someone trying it before we > ship new versions? :) > I'll try and test today. Thanks for addressing this before I even was aware it was a problem. ;) Is $c->prepare_body_chunk every called anymore? I'm wondering if that should be removed so that if someone's app is wrapping that they would see an error. That would identified this issue sooner, perhaps. I was looking at a separate issue where large uploads were stalling. That's when I noticed the progress bar not working. I saw in the logs was this: $ fgrep Read error_log Read error: Read error: Read error: Read error: followed immediately by a restart of the child process (testing with Starman). So, that's something else I need to try and track down. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
On 17 Oct 2012, at 07:13, Dimitar Petrov wrote: > Hey Bill, > > I think t0m fixed that a week ago in trunk and it should be working. You > might want to check the trunk of the Catalyst and the Plugin and to see if it > works for you and probably ask t0m to upload new version on CPAN. This needs a Catalyst release first - I was waiting till there were a few more changes for that, but if it's hurting people now, we could do a new version with just the tiny changes I made to support this. Can I get a 'yes this new code works' from someone trying it before we ship new versions? :) Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
Hey Bill,
I think t0m fixed that a week ago in trunk and it should be working. You
might want to check the trunk of the Catalyst and the Plugin and to see if
it works for you and probably ask t0m to upload new version on CPAN.
Here are the changes:
http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=commitdiff;h=0df490ef10f0a2deaa3b7950e721fa44659de860
http://dev.catalystframework.org/svnweb/Catalyst/revision?rev=14346
Cheers,
Dimitar
On Wed, Oct 17, 2012 at 2:16 AM, Bill Moseley wrote:
> At one point Catalyst::Engine did this:
>
> # Check for definedness as you could read '0'
> while ( defined ( my $buffer = $self->read($c) ) ) {
> $c->prepare_body_chunk($buffer);
> }
>
> Which meant that Catalyst::Plugin::UploadProgress could wrap/override
> $c->prepare_body_chunk.
>
> The code now does this ( in Catalyst::Request ):
>
>
> while ( defined ( my $buffer = $self->read() ) ) {
> $self->prepare_body_chunk($buffer);
> }
>
> Which breaks that functionality.
>
> How can I get the upload byte count into $c->cache so that my AJAX request
> can get updated upload stats?
>
> Thanks,
>
>
> --
> Bill Moseley
> mose...@hank.org
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
