Re: framework for modperl applications

2008-07-17 Thread W. Tyler Gee
On Thu, Jul 17, 2008 at 10:30 AM, Fred Moyer <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>>
>> I found that Catalyst is too huge to use.
>> Other than Catalyst, do you have any other framework suggested for MP
>> applications?
>> thanks.

My understanding is that Catalyst is as light as you want it to be.
What is 'heavy' about it?  What are you looking for in a framework?

>>
>> --penny
>
> Apache::Dispatch (http://search.cpan.org/dist/Apache-Dispatch) is on
> lightweight end of the spectrum, one step removed from writing your
> application using PerlResponseHandlers.  I'm not sure it qualifies as a
> framework though, maybe just a request framework.  It has been measured as
> almost as fast as straight response handlers (assuming that hasn't changed
> from 0.09 to 0.10).
>



-- 
~Tyler


Re: Caching a hash - am I missing something?

2008-08-19 Thread W. Tyler Gee
On Tue, Aug 19, 2008 at 5:35 PM, Chris Faust <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
> This might be a little off topic, I hope it's OK to post. I'm not positive
> if mod_perl matters or not because it's a little confusing to me.
>
>
>
> I've taken over some pretty old code that I'm updating and making mp2
> content handlers out of. The main script is a standard cgi script
> "start.cgi" there is nothing special in the apache conf for it.
>
>
>
> 
>
> SetHandler perl-script
>
> PerlFixupHandler My::Fixup
>
> PerlResponseHandler ModPerl::PerlRun
>
> PerlOptions +ParseHeaders
>
> DirectoryIndex start.cgi
>
> Options +ExecCGI +Indexes
>
> allow from all
>
> 
>
>
>
> start.cgi calls a custom module (use CustomModule;) which exports a bunch of
> subs, for example foobar and all over the place in the subs that are
> exported from CustomModule I see code like
>
>
>
>
>
> sub foobar {
>
> my $key = @_;
>
>
>
> if ($cache{$key}) {
>
> return $cache{$key};
>
> } else {
>
> my $do_some_query = ;
>
> $cache{$key} = $do_some_query_results
>
> return $cache{$key};
>
> }
>
> }
>
>
>
> My question is isn't the "else" in foobar always going to be true anyplace
> where start.cgi is calling "&foobar('somekey')"??
>
> I don't understand how %cache could already be populate from a previous
> browser request or something? I'm I just missing something stupid?

%cache is defined outside the scope of the sub so it will persist for
the lifetime of the apache server.  The very first time
foobar('somekey') is called it will do the query lookup, the next time
it will return from cache.

>
>
>
> FYI this was all running before on a version of Debian with old apache and
> old mod_perl (early 1.99 and 2.0.x). I've updated mod_perl to 2.0.2 and
> apache to 2.2 and everything still works.
>
>
>
> TIA!!
>
> -Chris
>
>
>
>
>
>
>
>
>
>
>
>
>
>



-- 
~Tyler


Re: Any success with storing photos in a database?

2008-09-29 Thread W. Tyler Gee
I'm pretty sure that the consensus is to never actually store the files in
the database.   What actual inconsistencies are you seeing that you are
trying to fix?

On Mon, Sep 29, 2008 at 1:00 PM, Mark Stosberg <[EMAIL PROTECTED]> wrote:

>
> This question isn't so much a mod_perl question, as it is a question
> about building high performance websites with Perl.
>
> We have a large, busy, database application that relates to millions of
> photos, which we also need to store and display. We've been keeping the
> meta data about the photos in PostgreSQL, and the files on the file
> system. (Implemented much like CGI::Uploader ).
>
> This has worked great in terms of performance, but with so much data to
> manage, over time we have run into data inconsistency issues between the
> file system and the database.
>
> So, I'm asking if anyone has had experience successfully storing photos
> (or othe files) directly in database? That would solve the consistency
> issue, but may create a performance issue. Perhaps the right kind of
> caching layer could solve that.
>
>Mark
>
> --
>  . . . . . . . . . . . . . . . . . . . . . . . . . . .
>   Mark StosbergPrincipal Developer
>   [EMAIL PROTECTED] Summersault, LLC
>   765-939-9301 ext 202 database driven websites
>  . . . . . http://www.summersault.com/ . . . . . . . .
>
>
>


-- 
~Tyler