Re: [Catalyst] Progress bar

2013-01-31 Thread Toby Corkindale
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

2012-10-26 Thread Bill Moseley
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

2012-10-25 Thread Aaron Trevena
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

2012-10-24 Thread Fred Moyer
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

2012-10-24 Thread Bill Moseley
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

2012-10-24 Thread Craig Chant
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

2012-10-24 Thread Lorn
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

2012-10-23 Thread Toby Corkindale
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

2012-10-21 Thread Bill Moseley
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

2012-10-20 Thread Tomas Doran
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

2012-10-19 Thread Tomas Doran

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

2012-10-18 Thread Bill Moseley
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

2012-10-17 Thread Tomas Doran

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

2012-10-17 Thread Bill Moseley
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

2012-10-17 Thread Bill Moseley
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

2012-10-17 Thread Tomas Doran

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

2012-10-16 Thread Dimitar Petrov
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/