Re: [cgiapp] ::Server vs ::Dispatch::Server: Worth having both?
Ricardo SIGNES writes: * Michael Peters [EMAIL PROTECTED] [2008-09-17T12:37:04] Bradley C Bailey wrote: In CAD::Server it tries to serve files staticly first before sending to dispatch. I think the best solution would be to specify a way to mark an entry point in the CA::Server config to specify static content. This would also improve performance since static content is more common than non-static (each non-static page probably links to at least a dozen static files). Patches welcome. Attached are four patches to CGI::Application::Server version 0.050 that implement various changes that have been discussed on the cgiapp mailing list. fix-pod.patch touches up the SYNOPSIS section to include 'use' statements for the various modules in the entry-points. fix-simple-use.patch moves HTTP::Server::Simple::Static from CGI::Application::Server's base class list to a simple use (pointed out by Bradley C. Bailey in the context of CGI::Application::Dispatch::Server). static-content.patch extends the entry-points table so that you can point specific entry-points at directories, which are then used as the docroot in a call to serve-static. fix-empty-target-take-2.patch provides support for dispatching on '/'. I created each of these patches by developing the patches on a subversion branch and then diffing the branch to the trunk. The static-content.patch creates two new directories in t/htdocs and populates them with simple index.html files that are used by the associated test script. I found that I needed to create these directories by hand before applying that patch or the index.html files weren't created (but patch didn't complain either...). I don't know if it's a freebsd-ism, or Go figure. The changes to the SYNOPSIS in fix-pod.patch and in fix-empty-target-take-2.patch overlap and if you apply them in the order they're listed above it causes a rejection. It's a simple one-line change to the SYNOPSIS. I'll leave it to all y'all to sort it out in your sandboxes. Here's what I did to test things. 527 7:57tar -xvf ../CGI-Application-Server-0.050.tar.gz 528 7:57cd CGI-Application-Server-0.050/ 529 7:57perl ./Build.PL 530 7:57./Build test 531 7:58patch /tmp/fix-pod.patch 532 7:58./Build test 533 7:58patch /tmp/fix-simple-use.patch 534 7:58./Build test 535 7:58mkdir t/htdocs/static 536 7:58mkdir t/htdocs/images 537 7:58patch /tmp/static-content.patch 538 7:58./Build test 539 7:59patch /tmp/fix-empty-target-take-2.patch 540 7:59cat lib/CGI/Application/Server.pm.rej 541 7:59./Build test 542 8:00history /tmp/patch-history Since there's a good chance that some part of the InterWeb Tube thingy will eat the attachments from this message, the patches are available at: http://shrimp.alerce.com/cgiapp g. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] ::Server vs ::Dispatch::Server: Worth having both?
Ricardo SIGNES writes: * Michael Peters [EMAIL PROTECTED] [2008-09-17T12:37:04] Bradley C Bailey wrote: In CAD::Server it tries to serve files staticly first before sending to dispatch. I think the best solution would be to specify a way to mark an entry point in the CA::Server config to specify static content. This would also improve performance since static content is more common than non-static (each non-static page probably links to at least a dozen static files). Patches welcome. I realized that I left some of the original code commented out in the static-content.patch branch. I cleaned it up, tested it again, updated the copy at http://shrimp.alerce.com/cgiapp, and have attached the cleaner copy here for posterity. Sorry for the noise. g. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] ::Server vs ::Dispatch::Server: Worth having both?
George Hartzell writes: [...] static-content.patch extends the entry-points table so that you can point specific entry-points at directories, which are then used as the docroot in a call to serve-static. Some self-feedback. Around line 83 of the patched Server.pm I checked to see if the directory exists and is *scannable*. In retrospect I think that I want *readable* (-r). I think that an existence test is redundant given the directory-ness test. The new serve_response method might be better called _serve_response, the privacy implied by a leading underscore would excuse the lack of pod documentation. Thoughts? g. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] ::Server vs ::Dispatch::Server: Worth having both?
CGI::Application::Dispatch::Server was released in Summer of '07, in part because CGI::Application::Server didn't have dispatching support. But soon after, in the fall, CGI::Application::Server was released, which supports both dispatched and regular CGI::App entry points. In reviewing the projects today, it seems likes CGI::Application::Server seems to cover all the bases. Is there any reason not to combine efforts and focus on just CGI::Application::Server ? As far as I can tell ::Dispatch::Server doesn't seem to offer much additional functionality, or a significantly different API. Having both will certainly be confusing some new users now due to the similarity. At a minimum, at least of them should document its differences and benefits over the other. Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] ::Server vs ::Dispatch::Server: Worth having both?
Mark,
CGI::Application::Dispatch::Server was released in Summer of '07, in part
because CGI::Application::Server didn't have dispatching support.
But soon after, in the fall, CGI::Application::Server was released, which
supports both dispatched and regular CGI::App entry points.
In reviewing the projects today, it seems likes CGI::Application::Server seems
to cover all the bases. Is there any reason not to combine efforts and focus on
just CGI::Application::Server ?
As far as I can tell ::Dispatch::Server doesn't seem to offer much additional
functionality, or a significantly different API.
Having both will certainly be confusing some new users now due to the similarity.
At a minimum, at least of them should document its differences and benefits over the other.
I fully agree here. The impression I got is that since there is a
CGI::Application::Dispatch::Server, then I must use that if I use CAD.
It's been a while since I looked at either closely, so I just looked at
the source and here are my first opinions of what would need to be done
to CA::Server to handle the way that I was using CAD::Server.
- Need a way to specify parameters to dispatch()
- Both handle output capturing different. Is one better than the other?
- The order in which static files is served is different.
I set up my apps so that / is dispatched, but /static maps to static
files. Looking at CA::Server, it does not appear that this would be
possible currently because it would always try and dispatch. In
CAD::Server it tries to serve files staticly first before sending to
dispatch. I think the best solution would be to specify a way to mark
an entry point in the CA::Server config to specify static content. Then
I could do something like this:
$server-entry_points({
'/' = 'My::App::Dispatch',
'/static' = undef, # or maybe even pass a directory path to
override document_root
});
Other than these points the code looks to be basically the same. I'd
like to see them combined.
Regards,
Bradley C Bailey
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] ::Server vs ::Dispatch::Server: Worth having both?
Bradley C Bailey wrote: In CAD::Server it tries to serve files staticly first before sending to dispatch. I think the best solution would be to specify a way to mark an entry point in the CA::Server config to specify static content. This would also improve performance since static content is more common than non-static (each non-static page probably links to at least a dozen static files). -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] ::Server vs ::Dispatch::Server: Worth having both?
* Michael Peters [EMAIL PROTECTED] [2008-09-17T12:37:04] Bradley C Bailey wrote: In CAD::Server it tries to serve files staticly first before sending to dispatch. I think the best solution would be to specify a way to mark an entry point in the CA::Server config to specify static content. This would also improve performance since static content is more common than non-static (each non-static page probably links to at least a dozen static files). Patches welcome. -- rjbs # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] ::Server vs ::Dispatch::Server: Worth having both?
Bradley C Bailey writes:
Mark,
CGI::Application::Dispatch::Server was released in Summer of '07, in part
because CGI::Application::Server didn't have dispatching support.
But soon after, in the fall, CGI::Application::Server was released, which
supports both dispatched and regular CGI::App entry points.
In reviewing the projects today, it seems likes CGI::Application::Server
seems
to cover all the bases. Is there any reason not to combine efforts and
focus on
just CGI::Application::Server ?
As far as I can tell ::Dispatch::Server doesn't seem to offer much
additional
functionality, or a significantly different API.
Having both will certainly be confusing some new users now due to the
similarity.
At a minimum, at least of them should document its differences and
benefits over the other.
I fully agree here. The impression I got is that since there is a
CGI::Application::Dispatch::Server, then I must use that if I use CAD.
It's been a while since I looked at either closely, so I just looked at
the source and here are my first opinions of what would need to be done
to CA::Server to handle the way that I was using CAD::Server.
- Need a way to specify parameters to dispatch()
- Both handle output capturing different. Is one better than the other?
- The order in which static files is served is different.
I set up my apps so that / is dispatched, but /static maps to static
files. Looking at CA::Server, it does not appear that this would be
possible currently because it would always try and dispatch. In
CAD::Server it tries to serve files staticly first before sending to
dispatch. I think the best solution would be to specify a way to mark
an entry point in the CA::Server config to specify static content. Then
I could do something like this:
$server-entry_points({
'/' = 'My::App::Dispatch',
'/static' = undef, # or maybe even pass a directory path to
override document_root
});
Other than these points the code looks to be basically the same. I'd
like to see them combined.
I think that it'd be great to retire
CGI::Application::Dispatch::Server once CGI::Application::Server
covers all of the bases.
I tried playing with it with my little demo app over last weekend and
got hung up on just the configuration described above. I haven't
figured out whether it was my doing something wrong or whether what I
want to do doesn't work in CGI::Application::Server.
I often have url's like
http://cgiapp:8080/Home/home
and dispatch them with My::App::Dispatch classes that look like this:
table = [
# things under the css banner get run through
# the css run-mode.
# eg: http://hostname/css/my.css
# app(package) is My::WebApp::CSS
# run_mode is css (My::WebApp::CSS::css)
# file is my.css
'css/:file' = {app = 'CSS',
rm = 'css',
},
# just match a single item and call it app
# eg: http://hostname/Home
# app (package) is My::WebApp::Home
# run_mode is whatever start mode Home declares.
':app' = {},
# match an app and a run_mode
# eg: http://hostname/Home/moose
# app (package) is My::WebApp::Home
# run_mode is moose (My::WebApp::Home::moose)
':app/:rm' = {},
],
I tried setting it up like this:
$server-entry_points({
'/' = 'My::App::Dispatch',
});
and couldn't get it to work. Using url's like:
http://cgiapp:8080/foo/Home/home
and
$server-entry_points({
'/foo' = 'My::App::Dispatch',
});
worked (some of the details above are from memory, I can't get to that
box from work).
I got to the point in valid_entry_point (I think...) where it loops
over the URI and it was exiting the while() loop without testing the
empty string after it chopped the last word off.
Does dispatching on '/' work for folks (was it operator error, or???)?
I can look into it a bit more over the weekend if it'd be useful.
If it isn't just me, then maybe just turning the while ($uri) {} into
do {} while($uri)?
If it is just me, anyone have a cluestick?
g.
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki:
