[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:
[cgiapp] Possible patches for ::Server (was: Re: ::Server vs ::Dispatch::Server: Worth having both?)
Patches welcome.
I'd like to provide feedback on various proposed changes to
CGI::Application::Server
Need a way to specify parameters to dispatch()
I disagree. The recommended way to do this to define a 'dispatch_args'
routine in your CGI::Application::Dispatch subclass. I think George
discovered seperately that the dispatch_args() method in
::Dispatch::Server was too magical for it's own good.
::Dispatch::Server prefers static files first, ::Server prefers dispatching
first
I think it is a bug in ::Server that it prefers dispatching server. The
recommended use of ::Dispatch, and also for Drupal, is to use a rewrite
rule that will serve static files directly if they match, otherwise the
request is passed on for possible dispatching. As Michael Peters pointed
out, this design should have better performance as well.
So Ricardo, would you accept a patch to change this ordering?
::Server doesn't dispatch / ?
I confirmed this. Looking at the code, it can be boiled down to this:
my $uri = /first/second;
while ( $uri ) {
print $uri\n;
# Remove the rightmost path element
$uri =~ s/\/[^\/]*$//;
}
That will print out /first/second and then /first, but never /. I
think this is a bug in ::Server. Richardo, would you accept a patch to
make / dispatchable? ( Would be treated the same ).
Both handle output capturing different. Is one better than the other?
I couldn't find anything that seemed worth changing in this regard, so
my take now is that ::Server is OK here.
Mark
--
http://mark.stosberg.com/
# 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] Possible patches for ::Server (was: Re: ::Server vs ::Dispatch::Server: Worth having both?)
* Mark Stosberg [EMAIL PROTECTED] [2008-09-17T20:57:37] ::Dispatch::Server prefers static files first, ::Server prefers dispatching first I think it is a bug in ::Server that it prefers dispatching server. The recommended use of ::Dispatch, and also for Drupal, is to use a rewrite rule that will serve static files directly if they match, otherwise the request is passed on for possible dispatching. As Michael Peters pointed out, this design should have better performance as well. So Ricardo, would you accept a patch to change this ordering? Almost certainly. I'll have to check with the other big user/maintainer. That will print out /first/second and then /first, but never /. I think this is a bug in ::Server. Richardo, would you accept a patch to make / dispatchable? ( Would be treated the same ). Only if you agree to never put an 'h' in my name again. -- 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/ ## ####
