Re: [Catalyst] Requirements for Catalyst
On Feb 21, 2009, at 9:42 PM, bill hauck wrote: I'd suggest getting a month with Linode and seeing how you like it. Thanks much to you and JRock. I took the plunge and it's pretty easy-- if a bit verbose installing everything--after all. On a side note I saw a preview of a Catalyst-centric host tonight but I don't know if I'm allowed to talk about it or if it'll debut any time soon so I'll just offer that teaser and head for the pillow. -Ashley ___ 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] Requirements for Catalyst
From: Jonathan Rockway j...@jrock.us * On Sat, Feb 21 2009, Ashley wrote: On Feb 21, 2009, at 3:04 PM, Jonathan Rockway wrote: We run lots of Catalyst apps on the smallest Linode. I think they give us something like 340M of RAM. This is enough. I use a 512M Slicehost for jrock.us, which runs my mail server and a few Catalyst applications Thank you all for your answers. It is great if Cat can work even with 256 MB of RAM. Octavian ___ 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/
[Catalyst] Google Summer of Code: mentors, projects
So, the Summer of Code is fast approaching, so I need two things out of you wonderful people: (1) if you think you might be able to mentor, yell - and outline what areas you think you'd prefer doing so in[0] (2) suggestions for projects that *would appeal to a student to work on.[1] Note that your suggestion will carry a lot more weight if you're willing to do the doc/writeup and even more if you're willing to mentor it :) We have a few people working on student recruitment, and I'll post later about how anybody else who wants to work that side of things can help out. For now, we need to make a list of mentors and projects so we can get that sent out and set up - if we don't get slots, nothing else matters sadly. Excessive bikeshedding will result in me resetting the thread with a new summary email and killfiling the old one; we don't have time for it, sorry. [0] note that you shouldn't worry too much about expertise here - I intend for a number of us to provide backup services to mentors in terms of technical knowledge, the key requirements here are interest and time [1] I'm not interested in your personal wishlist of features here, mine's probably at least as long as yours and I'm not inflicting it on the list just now so please show the same courtesy :) -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ 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] Re: decoding in core
On Fri, Feb 20, 2009 at 11:57:29AM -0600, Jonathan Rockway wrote:
The problem with writing a plugin or making this core is that people
really really want to misuse Unicode, and will whine when you try to
force correctness upon them.
I'm not sure what you mean by wanting to misuse Unicode. You mean
like decode using a different encoding than what the charset is in the
HTTP headers?
The only place where you are really allowed to use non-ASCII characters
are in the request and response. (HTTP has a way of representing the
character encoding of its payload -- URLs and Cookies don't.)
C::P::Unicode handles this correct usage correctly.
I disagree there. First, it assumes utf8 instead of what the
request states as the encoding. That is generally okay (where you set
accept-encoding in your forms), but why not decode as the request
states?
Second, it only decodes the request parameters. The body_parameters
and query_parameters are left undecoded.
Is that by design? That is, is it expected that in a POST
$c-req-parameters-{foo} would be characters where
$c-req-body_parameters-{foo} is undecoded octets? I would not want
or expect that.
The problem is that
people want Unicode to magically work where it's not allowed. This
includes HTTP headers (WTF!?), and URLs. (BTW, when I say Unicode, I
don't necessarily mean Unicode... I mean non-ASCII characters. The
Japanese character sets contain non-Unicode characters, and some people
want to put these characters in their URLs or HTTP headers. I wish I
was making ths up, but I am not. The Unicode process really fucked over
the Asian languages.)
I'm not sure we want to go down that path. Maybe a plugin for doing
crazy stuff with HTTP header encoding, but my initial email was really
just about moving decoding of the body (when we have a charset in the
request) and encoding on sending (again if there's a charset in the
response headers) into core.
Trying to do more than that is probably asking for headaches (and
whining).
I think there's reasonable debate at what point in the request
decoding should happen, though. Frankly, I'm not sure Catalyst should
decode, rather HTTP::Body should. HTTP::Body looks at the content
type header and if it's application/x-www-form-urlencoded it will
decode the body into separate parameters. But, why should it ignore
decoding the charset also specified?
The query parameters are more troublesome, of course. Seems the
common case is to use utf8 in URLs as the encoding, and in the end the
encoding just has to be assumed (or specified as a separate
parameter). uri_for()'s current behavior of encoding to utf8 is
probably a good way to go and to just always decoded the query
parameters as utf8 in Catalyst. I suppose uri_for() could add an
additional _enc=utf8 parameter to allow for different encodings, but
I can't imagine where just assuming utf8 would not be fine.
Of course, someone will want to mix encodings in different query
parameters.
There are subtle issues, like knowing not to touch XML (it's binary),
dealing with $c-res-body( filehandle ), and so on.
The layer can be set on the file handle. XML will be decoded as
application/octet-stream by HTTP::Body, so that should be ok.
Although, if there's a chraset in the request I would still
probably argue that decoding would be the correct thing to do.
For custom processing I currently extend HTTP::Body. For example:
$HTTP::Body::TYPES-{'text/xml'} = 'My::XML::Parser';
which does stream parsing of the XML and thus handles the XML
charset decoding.
One last thing, if this becomes core, it will definitely break people's
apps. Many, many apps are blissfully unaware of characters and treat
text as binary... and their apps kind-of appear to work. As soon as
they get some real characters in their app, though, they will have
double-encoded nonsense all over the place, and will blame you for this.
That may be true for some. For most they probably have simply ignored
encoding and don't realize they are working with octets instead of
characters, and thanks to Perl it just all works. So working with
real characters instead will likely be transparent for them.
Catalyst::Plugin::Unicode blindly decodes using utf::decode() and I
think that's a no-op if the content has already been decoded (utf8
flag is already set). Likewise, it only encodes if the utf8 flag is
set. So, users of that plugin should be ok if character encoding
was handled in core and they don't remove the plugin.
--
Bill Moseley
mose...@hank.org
Sent from my iMutt
___
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] Maybe there is a need for some speedups of 'config' method ?
*we should now - we should not :-)
2009/2/22 Oleg Pronin syber@gmail.com
1% here and 1% there. You won't detect any place that takes longer. All of
load is 1%+1%+
Don't you agree ? Plus a number of plugins calls -config on startup which
slow downs startup as well)
P.S.
I use many actions that take params from config in runtime, for example
sub pay_for_vip : Private {
...
my $price = $c-cfg-{vip}{price};
}
And in my deepest opinion we should now spend CPU time anywhere even if it
is not a concern.
Thanks anyway)
This is convenient + good HUP support for deamon servers (that use catalyst
as well) - all you need to do is to refresh config on HUP.
2009/2/22 Jonathan Rockway j...@jrock.us
* On Sat, Feb 21 2009, Oleg Pronin wrote:
I use Catalyst in extremely loaded projects (currently 60.000.000
pageloads / day).
Thereforce i'm perfomance paranoid man.
One of 'black stones' is the -config method. It has dramatically slow
perfomance at
config_method: 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @
3808.94/s (n=
4047)
I have to ask... is this actually slowing down your application? Let's
say that your app spends 1% of its time in $c-config. If you made
$c-config 1x faster, you would only make your app 1% faster.
It would be VERY GREAT if we somehow make -config works a hundred
times faster because everybody use -config without any suspicions on
its speed.
Although I haven't noticed config calls slowing down my application, I
look forward to seeing your patch for this.
FWIW, I usually only call $c-config at app startup time; I read it and
pass values in it as arguments to other classes that need configuration
information. I'm pretty sure this is the intended use; you shouldn't be
looking in it during requests.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
___
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] Maybe there is a need for some speedups of 'config' method ?
1% here and 1% there. You won't detect any place that takes longer. All of
load is 1%+1%+
Don't you agree ? Plus a number of plugins calls -config on startup which
slow downs startup as well)
P.S.
I use many actions that take params from config in runtime, for example
sub pay_for_vip : Private {
...
my $price = $c-cfg-{vip}{price};
}
And in my deepest opinion we should now spend CPU time anywhere even if it
is not a concern.
Thanks anyway)
This is convenient + good HUP support for deamon servers (that use catalyst
as well) - all you need to do is to refresh config on HUP.
2009/2/22 Jonathan Rockway j...@jrock.us
* On Sat, Feb 21 2009, Oleg Pronin wrote:
I use Catalyst in extremely loaded projects (currently 60.000.000
pageloads / day).
Thereforce i'm perfomance paranoid man.
One of 'black stones' is the -config method. It has dramatically slow
perfomance at
config_method: 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @
3808.94/s (n=
4047)
I have to ask... is this actually slowing down your application? Let's
say that your app spends 1% of its time in $c-config. If you made
$c-config 1x faster, you would only make your app 1% faster.
It would be VERY GREAT if we somehow make -config works a hundred
times faster because everybody use -config without any suspicions on
its speed.
Although I haven't noticed config calls slowing down my application, I
look forward to seeing your patch for this.
FWIW, I usually only call $c-config at app startup time; I read it and
pass values in it as arguments to other classes that need configuration
information. I'm pretty sure this is the intended use; you shouldn't be
looking in it during requests.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
___
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: RFC local::lib + CPAN shell support in CatalystX::Starter (was:Re: [Catalyst] RFC: The paradox of choice in web development)
-Original Message- From: Tomas Doran [mailto:bobtf...@bobtfish.net] Sent: Friday, February 20, 2009 3:16 AM To: The elegant MVC web framework Subject: Re: RFC local::lib + CPAN shell support in CatalystX::Starter (was:Re: [Catalyst] RFC: The paradox of choice in web development) On 19 Feb 2009, at 18:27, Matt Pitts wrote: All this talk about Perl/Catalyst/CPAN pains, has got me thinking... Anybody like the idea of having a local::lib bootstrap option to CatalystX::Starter and possible integration of a script that would launch a CPAN shell for installing into the local::lib folder? CatalystX::Starter is for boot strapping a Catalyst component, not an application. You'd be looking to add to Catalyst::Devel Ok, I see why it shouldn't be in CX::Starter, but if it's in C::Devel it defeats the purpose of it being a bootstrapper because C::Devel requires Catalyst. My thinking was to have a system with an absolute minimum Perl/CPAN install. My current baseline is an up-to-date CPAN (1.92+) via Bundle::CPAN and Path::Class, but after that no other dists installed system-wide. For this reason, I was imagining a stand-a-lone dist (CatalystX::Bootstrapper?) that itself only requires Path::Class, local::lib and maybe a couple of other basic modules. The usage would then look something like: $ perl -MCPAN -e 'install CatalystX::Bootstrapper' ... $ catalystx_bootstrapper.pl MyApp $ cd MyApp $ script/myapp_server.pl The only trick to this is that the bootstrapper command would have to do all of the following: - setup initial directories (MyApp, MyApp/locallib, MyAPP/script) - write its files (script/AppBootstrap.pm, script/myapp_cpan_shell.pl) - invoke the CPAN shell for the 1st time to install (Catalyst, Catalyst::Devel, others) this is the tricky part - invoke catalyst.pl MyApp (the one now installed under locallib) to actually generate the app - patch the newly created script files to use AppBootstrap.pm (maybe there's a way to hook catalyst.pl instead of doing this?) This all might be a bit rough, maybe folks out there have some better ideas. Or, maybe a separate module Catalyst::Starter::LocalLib? The idea would be to help folks bootstrap Cat apps and get all the deps inside the app folder right from the start for easier deployment. Of course it won't eliminate the need for a shell, but it's still an improvement. You'd be looking to have local::lib support built into the scripts etc which Catalyst generates, and an additional shell script in your scripts directory to start a CPAN shell pointing at your application's local::lib and tricks to install all the non perl core dependencies into that directory? Actually, the bootstrapper CPAN shell script would install everything into locallib. If the user wants something installed system-wide, they can just use a normal cpan shell. Ideally, the bootstrapper wouldn't make any assumptions about what should go where. That sounds like a good idea, and I've considered hacking on it myself, but never found the tuits. I currently have this working well for me across a couple of apps. Using local::lib it didn't turn out to be as tricky as I thought it might, but I still have trouble with Module::Build based modules because sometimes it doesn't honor --install_base -or- wants to use an existing one even though o conf mbuildpl_arg was set. The other part of this worth mentioning is that all the bootstrap code is in a separate file (script/AppBootstrap.pm), which makes it easy for additional scripts to bootstrap the local libs like so: use FindBin; use lib($FindBin::Bin); use AppBootstrap; I'm doing this for multiple scripts that need MyApp-... for various jobs as well as _server.pl, etc. I could probably put together a patch if I can get some best practice ideas. I'm thinking of rails' ability to 'freeze' rails into your application here. In actual fact, I've never found this feature very useful as I want to freeze all the dependencies too (this is possible, but involves hacking environment.rb and etc in the same way as manually attaching a local::lib to your Cat app). I haven't played with Rails enough to get this far. Sounds similar, though. I guess the biggest argument is likely to be what the correct name for the directory containing your local::lib is. I also expect there would be a fair amount of toolchain related yak-shaving to get it right, but its certainly a feature I'd like to see happen. Currently, I'm just calling the directory 'locallib', but since the idea of the module would be a bootstrapper, the name could be a command-line option that then becomes hard-coded into the bootstrap code. Also, no yak-shaving as of yet, but there might be some things I'm missing. Thanks for your input t0m. v/r -matt pitts ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
RE: [Catalyst] RFC: The paradox of choice in web development
-Original Message- From: Tomas Doran [mailto:bobtf...@bobtfish.net] Sent: Friday, February 20, 2009 4:08 AM To: The elegant MVC web framework Subject: Re: [Catalyst] RFC: The paradox of choice in web development On 19 Feb 2009, at 20:07, Matt Pitts wrote: -Original Message- From: Dave Rolsky [mailto:auta...@urth.org] Sent: Thursday, February 19, 2009 2:21 PM To: The elegant MVC web framework Subject: RE: [Catalyst] RFC: The paradox of choice in web development On Thu, 19 Feb 2009, Matt Pitts wrote: I myself am currently trying to support multiple developers (content perl) working on a Catalyst app from Windows desktops and it's been a snip Getting _way_ off-topic, but if your target environment is Linux, this is insane. VMWare is easy to set up and would let your Windows developer run the app in something much closer to its target environment. Thanks for the input... VMs were considered as an option, but since the Windows folks aren't Linux-savvy, this means even more systems I have to maintain, perl CPAN, updates, etc. Where are you finding perl programmers from who can't use ubuntu? We're not, 2 of the devs are content guys who also work on M$ projects (.NET). I don't expect them to learn Ubuntu nor do I want to further confuse their day-to-day work effort by making them boot a VM and learn basic Linux skills in order to work on this one client (yes, we only have one Perl/Catalyst client right now). Maybe I'm being too nice. The other dev (besides me) also works on M$ projects as a coder and has become our Perl newbie - she volunteered to learn Perl/Catalyst and become my backup. The Perl newbie is open to whatever method I want to use for her to run the app, but the content devs would have a tough go with VMs and I don't want to support more than one type of DEV environment. Also, how does having people building software for a platform they're unfamiliar with work for you? Because we're a small outfit and we're trying to stay lean due to the current economy. Hiring any more full-up Perl devs is not an option. Yes, it's a risk, but it's one we're probably just going to live with. Besides, part of the appeal of Catalyst (and web frameworks in general) is that they abstract away the low-level details, so for my perl newbie I don't consider her role Linux dev, I consider it Perl/Catalyst dev. Maybe that will change once she feels more comfortable with Perl/Catalyst, but for now, she's helping to offload some of my work and it makes a big difference. I actually have time to participate in the mailing list now :-). Not to mention the system resources used by the VM which could be quite taxing on some of our developers' systems. For me, this was the insane option. I'm sorry, but if you're not prepared to buy your developers reasonable workstations then you've already lost - it doesn't take much effort to do a cost/benefit analysis and the cost of developing on a platform which (a) is causing you pain, and (b) is nothing like your production environment. Agreed and if I really wanted to run VMs I'm confident that the $boss would approve any performance upgrades necessary for users' machines. As for (b), I have been very impressed with Catalyst's cross-platform consistency. After 2 years of production (SLES10 on x86_64), I've never once had a bug related to actual app code (not performance or server config related) that I couldn't duplicate in DEV (either cgywin or Ubuntu x86). This cost cannot be trivial even with the simple factors, and even higher once you factor less easy to analyze things such as the additional risk of your software having had less testing an the correct environment, and the staff motiviation as developing your application sounds painful. How many days of lost time/work is the cost of a reasonable workstation? 2, 3? Less than a week certainly.. The highest cost to a knowledge based organisation is human resources, and so not providing your people the right kit to do their jobs effectively is just cutting your own throat. Agreed. Agreed. Agreed. In reality, two of the devs _are_ currently running the app on Linux, in their $HOME on a shared DEV server, and using Samba to access their $HOME from windows. This setup has its own issues that I won't go into. Shared dev servers are fail to start with for a number of reasons - each developer needs their own environment they can mess up as they wish. That aside, I don't see why there is any need to share a home directory between where you're developing and where your workstation is - all your code is in revision control, right? I suppose you'd want this if you used a graphical editor, but remote X works nicely in cygwin, so that could theoretically be a solution (other than the fact that having several people run a desktop environment on the same box is going to suck pretty quickly). Because the
Re: [Catalyst] stripping path parts and then redispatch?
Hi Tomas - I'm using Catalyst 5.8.5 so I can make use of any of forward, detach, visit, go, etc. Not helpful to your main email, but there is no such version as 5.8.5? I assume you mean 5.8000_05, which is a developer release? Yes, that's what I meant, sorry. Larry ___ 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] stripping path parts and then redispatch?
On 22 Feb 2009, at 22:28, Larry Leszczynski wrote: I'm using Catalyst 5.8.5 so I can make use of any of forward, detach, visit, go, etc. Not helpful to your main email, but there is no such version as 5.8.5? I assume you mean 5.8000_05, which is a developer release? 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] stripping path parts and then redispatch?
On Sun, Feb 22, 2009 at 03:28:48PM -0700, Larry Leszczynski wrote: I'd like to be able to capture and strip off the language, in e.g. MyApp::Controller::Root::auto(), and then either forward or redispatch to the existing controllers, but haven't been able to come up with a way of generating the forwarding path/args that consistently works for all action types. E.g., how do I know if I should dispatch to action /foo/bar, or action /foo with argument bar? I'm sure there's better approach, but I've simply overridden prepare_path and then removed the prefix (e.g. the language) from the path, set a flag, and then appended it on $req-base. -- Bill Moseley mose...@hank.org Sent from my iMutt ___ 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] stripping path parts and then redispatch?
On Sun, Feb 22, 2009 at 11:28 PM, Larry Leszczynski lar...@emailplus.org wrote: I have an existing site, and want to add the page language to the URLs so that caching will work correctly, e.g. /foo/bar would now look like /en/foo/bar or /fr/foo/bar. (The language is user-selected, not from browser prefs, so setting the Vary: Accept-Language response header won't help.) Apart from the missing true return value from auto, this works: http://lists.scsys.co.uk/pipermail/catalyst/2009-February/021072.html -- Lars Balker RasmussenConsult::Perl ___ 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] Maybe there is a need for some speedups of 'config' method ?
* On Sun, Feb 22 2009, Oleg Pronin wrote: And in my deepest opinion we should now spend CPU time anywhere even if it is not a concern. You forgot to attach the patch. /mst Seriously, you obviously think this is worth spending time on, so spend the time on it, and it will be fixed for everyone! That is what free software is all about. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ 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/
