Skip Menu |

This queue is for tickets about the Server-Control CPAN distribution.

Report information
The Basics
Id: 79010
Status: resolved
Priority: 0/
Queue: Server-Control

People
Owner: Nobody in particular
Requestors: RSAVAGE [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.19
Fixed in: (no value)



Subject: Could code auto-generate starman options?
Hi I'd like to see the code auto-generate the starman options: options => { listen => '127.0.0.1:5002', pid => "$pid_file_name", workers => 1, # OK, Not this one! }, since the listen and pid values are available already, given: my($server) = Server::Control::Starman -> new ( app_psgi => "$app_path", binary_path => "$binary_path", bind_addr => '127.0.0.1', # error_log => "$error_file_name", log_dir => "$log_dir_name", name => 'Local::Application', options => { listen => '127.0.0.1:5002', pid => "$pid_file_name", workers => 1, }, pid_file => "$pid_file_name", port => 5002, server_root => "$app_dir_name", wait_for_status_secs => 2, );
Subject: Re: [rt.cpan.org #79010] Could code auto-generate starman options?
Date: Thu, 16 Aug 2012 04:50:32 -0700
To: bug-Server-Control [...] rt.cpan.org
From: Jonathan Swartz <swartz [...] pobox.com>
Well, right now it auto-generates the Server::Control::Starman parameters based on the starman options. Are you saying you want it to auto-generate the other way too? That sounds complicated. Patches welcome. :) On Aug 15, 2012, at 9:20 PM, RSAVAGE via RT wrote: Show quoted text
> Thu Aug 16 00:20:58 2012: Request 79010 was acted upon. > Transaction: Ticket created by RSAVAGE > Queue: Server-Control > Subject: Could code auto-generate starman options? > Broken in: 0.19 > Severity: Normal > Owner: Nobody > Requestors: RSAVAGE@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79010 > > > > Hi > > I'd like to see the code auto-generate the starman options: > > options => > { > listen => '127.0.0.1:5002', > pid => "$pid_file_name", > workers => 1, # OK, Not this one! > }, > since the listen and pid values are available already, given: > > my($server) = Server::Control::Starman -> new > ( > app_psgi => "$app_path", > binary_path => "$binary_path", > bind_addr => '127.0.0.1', > # error_log => "$error_file_name", > log_dir => "$log_dir_name", > name => 'Local::Application', > options => > { > listen => '127.0.0.1:5002', > pid => "$pid_file_name", > workers => 1, > }, > pid_file => "$pid_file_name", > port => 5002, > server_root => "$app_dir_name", > wait_for_status_secs => 2, > ); >
Subject: Re: [rt.cpan.org #79010] Could code auto-generate starman options?
Date: Fri, 17 Aug 2012 10:23:15 +1000
To: bug-Server-Control [...] rt.cpan.org
From: Ron Savage <ron [...] savage.net.au>
Hi Jonathan On 16/08/12 21:50, Jonathan Swartz via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=79010> > > Well, right now it auto-generates the Server::Control::Starman parameters based on the starman options. Are you saying you want it to auto-generate the other way too? That sounds complicated. Patches welcome. :)
1) OK. I can't see where in the docs it says that (hint, hint). But now there's another problem: When I comment out both bind_addr and port, I get an error: cannot determine port at /home/ron/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/Server/Control/Starman.pm line 57. Whereas when I only comment out bind_addr, it runs ok (as expected). But I'm guessing that's because it defaults to localhost (the only case I use, so far) and not because it parses the Starman opts. Or is the code smarter than I'm thinking :-)? 2) And yes, I was expecting the code to parse the Server::Control options and use them to fill in any necessary in the required Startman options. After all, why should I code that when I can get you to do it for me :-))? But seriously, if you do it, all end-users will be relieved of that effort, which is just duplication. Cheers Show quoted text
> On Aug 15, 2012, at 9:20 PM, RSAVAGE via RT wrote: >
>> Thu Aug 16 00:20:58 2012: Request 79010 was acted upon. >> Transaction: Ticket created by RSAVAGE >> Queue: Server-Control >> Subject: Could code auto-generate starman options? >> Broken in: 0.19 >> Severity: Normal >> Owner: Nobody >> Requestors: RSAVAGE@cpan.org >> Status: new >> Ticket<URL: https://rt.cpan.org/Ticket/Display.html?id=79010> >> >> >> Hi >> >> I'd like to see the code auto-generate the starman options: >> >> options => >> { >> listen => '127.0.0.1:5002', >> pid => "$pid_file_name", >> workers => 1, # OK, Not this one! >> }, >> since the listen and pid values are available already, given: >> >> my($server) = Server::Control::Starman -> new >> ( >> app_psgi => "$app_path", >> binary_path => "$binary_path", >> bind_addr => '127.0.0.1', >> # error_log => "$error_file_name", >> log_dir => "$log_dir_name", >> name => 'Local::Application', >> options => >> { >> listen => '127.0.0.1:5002', >> pid => "$pid_file_name", >> workers => 1, >> }, >> pid_file => "$pid_file_name", >> port => 5002, >> server_root => "$app_dir_name", >> wait_for_status_secs => 2, >> ); >>
> > > >
-- Ron Savage http://savage.net.au/ Ph: 0421 920 622
Subject: Re: [rt.cpan.org #79010] Could code auto-generate starman options?
Date: Thu, 16 Aug 2012 17:30:55 -0700
To: bug-Server-Control [...] rt.cpan.org
From: Jonathan Swartz <swartz [...] pobox.com>
In the docs, it says: This module will determine "error_log" in Server::Control, "pid_file" in Server::Control, and "port" in Server::Control from the options hash. and in the synopsis: my $starman = Server::Control::Starman->new( binary_path => '/usr/local/bin/starman' options => { port => 123, error_log => '/path/to/error.log', pid_file => '/path/to/starman.pid' }, ); But obviously that needs to be made clearer. Either you specify the starman options and those are used to populate Server::Control parameters, or you specify Server::Control parameters and those are used to popular starman options. Trying to do it in both directions would be confusing and hard to test all cases (e.g. what if you passed some to starman options and some to Server::Control parameters). So I chose the former. Maybe 'options' is too generic and needs to be renamed, e.g. 'starman_options'? Then I can say in the docs that "error_log, pid_file, and port will be determined from the starman_options hash". Would that make it clearer? Jon On Aug 16, 2012, at 5:22 PM, ron@savage.net.au via RT wrote: Show quoted text
> Queue: Server-Control > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79010 > > > Hi Jonathan > > On 16/08/12 21:50, Jonathan Swartz via RT wrote:
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=79010> >> >> Well, right now it auto-generates the Server::Control::Starman parameters based on the starman options. Are you saying you want it to auto-generate the other way too? That sounds complicated. Patches welcome. :)
> > 1) OK. I can't see where in the docs it says that (hint, hint). > > But now there's another problem: When I comment out both bind_addr and > port, I get an error: > > cannot determine port at > /home/ron/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/Server/Control/Starman.pm > line 57. > > Whereas when I only comment out bind_addr, it runs ok (as expected). > > But I'm guessing that's because it defaults to localhost (the only case > I use, so far) and not because it parses the Starman opts. Or is the > code smarter than I'm thinking :-)? > > 2) And yes, I was expecting the code to parse the Server::Control > options and use them to fill in any necessary in the required Startman > options. > > After all, why should I code that when I can get you to do it for me :-))? > > But seriously, if you do it, all end-users will be relieved of that > effort, which is just duplication. > > Cheers >
>> On Aug 15, 2012, at 9:20 PM, RSAVAGE via RT wrote: >>
>>> Thu Aug 16 00:20:58 2012: Request 79010 was acted upon. >>> Transaction: Ticket created by RSAVAGE >>> Queue: Server-Control >>> Subject: Could code auto-generate starman options? >>> Broken in: 0.19 >>> Severity: Normal >>> Owner: Nobody >>> Requestors: RSAVAGE@cpan.org >>> Status: new >>> Ticket<URL: https://rt.cpan.org/Ticket/Display.html?id=79010> >>> >>> >>> Hi >>> >>> I'd like to see the code auto-generate the starman options: >>> >>> options => >>> { >>> listen => '127.0.0.1:5002', >>> pid => "$pid_file_name", >>> workers => 1, # OK, Not this one! >>> }, >>> since the listen and pid values are available already, given: >>> >>> my($server) = Server::Control::Starman -> new >>> ( >>> app_psgi => "$app_path", >>> binary_path => "$binary_path", >>> bind_addr => '127.0.0.1', >>> # error_log => "$error_file_name", >>> log_dir => "$log_dir_name", >>> name => 'Local::Application', >>> options => >>> { >>> listen => '127.0.0.1:5002', >>> pid => "$pid_file_name", >>> workers => 1, >>> }, >>> pid_file => "$pid_file_name", >>> port => 5002, >>> server_root => "$app_dir_name", >>> wait_for_status_secs => 2, >>> ); >>>
>> >> >> >>
> > > -- > Ron Savage > http://savage.net.au/ > Ph: 0421 920 622 >
Subject: Re: [rt.cpan.org #79010] Could code auto-generate starman options?
Date: Fri, 17 Aug 2012 10:39:32 +1000
To: bug-Server-Control [...] rt.cpan.org
From: Ron Savage <ron [...] savage.net.au>
Hi Jon On 17/08/12 10:31, Jonathan Swartz via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=79010> > > > In the docs, it says: > > This module will determine "error_log" in Server::Control, "pid_file" in Server::Control, and "port" in Server::Control from the options hash. > > and in the synopsis: > > my $starman = Server::Control::Starman->new( > binary_path => '/usr/local/bin/starman' > options => { > port => 123, > error_log => '/path/to/error.log', > pid_file => '/path/to/starman.pid' > }, > ); > > But obviously that needs to be made clearer. > > Either you specify the starman options and those are used to populate Server::Control parameters, or you specify Server::Control parameters and those are used to popular starman options. Trying to do it in both directions would be confusing and hard to test all cases (e.g. what if you passed some to starman options and some to Server::Control parameters). So I chose the former. > > Maybe 'options' is too generic and needs to be renamed, e.g. 'starman_options'? Then I can say in the docs that "error_log, pid_file, and port will be determined from the starman_options hash". Would that make it clearer?
An instantaneous thought is Yes, use starman options, but a moment's reflection says no. The problem is that that (potentially) leads to each sub-class having a differently named option hash. I think that's too confusing. So I'd stick with options, and somehow re-word the text, and not just in the sub-class docs. In the Server::Control docs precede the discussion of options with something like: Certain options are auto-populated from the sub-class-specific options hash (if any). And for each such option (yes I know its work) add a comment about auto-population from the sub-class-specific hash. Show quoted text
> Jon > > On Aug 16, 2012, at 5:22 PM, ron@savage.net.au via RT wrote: >
>> Queue: Server-Control >> Ticket<URL: https://rt.cpan.org/Ticket/Display.html?id=79010> >> >> Hi Jonathan >> >> On 16/08/12 21:50, Jonathan Swartz via RT wrote:
>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=79010> >>> >>> Well, right now it auto-generates the Server::Control::Starman parameters based on the starman options. Are you saying you want it to auto-generate the other way too? That sounds complicated. Patches welcome. :)
>> >> 1) OK. I can't see where in the docs it says that (hint, hint). >> >> But now there's another problem: When I comment out both bind_addr and >> port, I get an error: >> >> cannot determine port at >> /home/ron/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/Server/Control/Starman.pm >> line 57. >> >> Whereas when I only comment out bind_addr, it runs ok (as expected). >> >> But I'm guessing that's because it defaults to localhost (the only case >> I use, so far) and not because it parses the Starman opts. Or is the >> code smarter than I'm thinking :-)? >> >> 2) And yes, I was expecting the code to parse the Server::Control >> options and use them to fill in any necessary in the required Startman >> options. >> >> After all, why should I code that when I can get you to do it for me :-))? >> >> But seriously, if you do it, all end-users will be relieved of that >> effort, which is just duplication. >> >> Cheers >>
>>> On Aug 15, 2012, at 9:20 PM, RSAVAGE via RT wrote: >>>
>>>> Thu Aug 16 00:20:58 2012: Request 79010 was acted upon. >>>> Transaction: Ticket created by RSAVAGE >>>> Queue: Server-Control >>>> Subject: Could code auto-generate starman options? >>>> Broken in: 0.19 >>>> Severity: Normal >>>> Owner: Nobody >>>> Requestors: RSAVAGE@cpan.org >>>> Status: new >>>> Ticket<URL: https://rt.cpan.org/Ticket/Display.html?id=79010> >>>> >>>> >>>> Hi >>>> >>>> I'd like to see the code auto-generate the starman options: >>>> >>>> options => >>>> { >>>> listen => '127.0.0.1:5002', >>>> pid => "$pid_file_name", >>>> workers => 1, # OK, Not this one! >>>> }, >>>> since the listen and pid values are available already, given: >>>> >>>> my($server) = Server::Control::Starman -> new >>>> ( >>>> app_psgi => "$app_path", >>>> binary_path => "$binary_path", >>>> bind_addr => '127.0.0.1', >>>> # error_log => "$error_file_name", >>>> log_dir => "$log_dir_name", >>>> name => 'Local::Application', >>>> options => >>>> { >>>> listen => '127.0.0.1:5002', >>>> pid => "$pid_file_name", >>>> workers => 1, >>>> }, >>>> pid_file => "$pid_file_name", >>>> port => 5002, >>>> server_root => "$app_dir_name", >>>> wait_for_status_secs => 2, >>>> ); >>>>
>>> >>> >>> >>>
>> >> >> -- >> Ron Savage >> http://savage.net.au/ >> Ph: 0421 920 622 >>
> > > >
-- Ron Savage http://savage.net.au/ Ph: 0421 920 622
Subject: Re: [rt.cpan.org #79010] Could code auto-generate starman options?
Date: Fri, 17 Aug 2012 17:09:58 -0700
To: bug-Server-Control [...] rt.cpan.org
From: Jonathan Swartz <swartz [...] pobox.com>
On Aug 16, 2012, at 5:38 PM, ron@savage.net.au via RT wrote: Show quoted text
> Queue: Server-Control > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79010 > > > Hi Jon > > On 17/08/12 10:31, Jonathan Swartz via RT wrote:
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=79010> >> >> >> In the docs, it says: >> >> This module will determine "error_log" in Server::Control, "pid_file" in Server::Control, and "port" in Server::Control from the options hash. >> >> and in the synopsis: >> >> my $starman = Server::Control::Starman->new( >> binary_path => '/usr/local/bin/starman' >> options => { >> port => 123, >> error_log => '/path/to/error.log', >> pid_file => '/path/to/starman.pid' >> }, >> ); >> >> But obviously that needs to be made clearer. >> >> Either you specify the starman options and those are used to populate Server::Control parameters, or you specify Server::Control parameters and those are used to popular starman options. Trying to do it in both directions would be confusing and hard to test all cases (e.g. what if you passed some to starman options and some to Server::Control parameters). So I chose the former. >> >> Maybe 'options' is too generic and needs to be renamed, e.g. 'starman_options'? Then I can say in the docs that "error_log, pid_file, and port will be determined from the starman_options hash". Would that make it clearer?
> > An instantaneous thought is Yes, use starman options, but a moment's > reflection says no. > > The problem is that that (potentially) leads to each sub-class having a > differently named option hash. I think that's too confusing. So I'd > stick with options, and somehow re-word the text, and not just in the > sub-class docs. In the Server::Control docs precede the discussion of > options with something like: > > Certain options are auto-populated from the sub-class-specific options > hash (if any). > > And for each such option (yes I know its work) add a comment about > auto-population from the sub-class-specific hash. >
Right now Starman is the only one of the three main subclasses that takes an options hash in this way. The others (Nginx, Apache, and eventually Lighttpd) use a conf file. But I'll work on making the docs clearer. Jon
Subject: Re: [rt.cpan.org #79010] Could code auto-generate starman options?
Date: Sun, 19 Aug 2012 10:46:48 +1000
To: bug-Server-Control [...] rt.cpan.org
From: Ron Savage <ron [...] savage.net.au>
Hi Jon On 18/08/12 16:28, Jonathan Swartz via RT wrote: Show quoted text
> Right now Starman is the only one of the three main subclasses that takes an options hash in this way. The others (Nginx, Apache, and eventually Lighttpd) use a conf file. > > But I'll work on making the docs clearer.
OK. Thanx. That'll do! -- Ron Savage http://savage.net.au/ Ph: 0421 920 622