Hi,
I just got done using win32/service to run a very small/hack-ish
"Riki"
WEBrick service. Very cool stuff. Thanks.
So, in the process, I noticed a lot of the "control"
start/install/etc.
command line parser stuff looked a bit boilerplate, so I pulled it out into
a helper function "service_cli" (for lack of a better name).
Its simple, but it allows me to do away with a Riki-specific control script.
So I can just do:
riki.rb:
----
$LOAD_PATH.unshift File.dirname(__FILE__)
require ''service_cli''
class RikiDaemon < Win32::Daemon
def self.setup(s)
s.binary_path_name = "ruby #{__FILE__} --service"
end
...service_main/service_stop...
end
service_cli(''Riki'', RikiDaemon)
----
So now the "control" and "daemon" functions are both handled
from the same
generic script (I added an odd but effective command line parameter of
--service which means its getting started by win32 and should call
daemon_class.new.mainloop).
And now "service_cli.rb" is just generic code I could potentially
reuse
across other services.
So, I dunno, perhaps this is too simple or utility-ish, but it has the
potential to remove ~50 lines of boilerplate control/command line code, so I
thought maybe I''d send it in and see if it was interesting enough to
include
in the distribution.
(Also, I apologize if you''re getting this twice, but I sent this about
a
week ago but from an email address other than the one I signed up to the
list for, so it likely did not go through. Since then, I have added a
-a/--standalone flag for easily starting the service_main/service_stop for
debugging purposes and thought I''d submit it again.)
Thanks,
Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: service_cli.rb
Type: application/octet-stream
Size: 2288 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/win32utils-devel/attachments/20051130/9fa1ee67/service_cli.obj
Stephen Haberman wrote:> Hi, > > I just got done using win32/service to run a very small/hack-ish "Riki" > WEBrick service. Very cool stuff. Thanks. > > So, in the process, I noticed a lot of the "control" start/install/etc. > command line parser stuff looked a bit boilerplate, so I pulled it out into > a helper function "service_cli" (for lack of a better name). > > Its simple, but it allows me to do away with a Riki-specific control script. > So I can just do: > > riki.rb: > ---- > > $LOAD_PATH.unshift File.dirname(__FILE__) > require ''service_cli'' > > class RikiDaemon < Win32::Daemon > def self.setup(s) > s.binary_path_name = "ruby #{__FILE__} --service" > end > ...service_main/service_stop... > end > > service_cli(''Riki'', RikiDaemon) > > ---- > > So now the "control" and "daemon" functions are both handled from the same > generic script (I added an odd but effective command line parameter of > --service which means its getting started by win32 and should call > daemon_class.new.mainloop). > > And now "service_cli.rb" is just generic code I could potentially reuse > across other services. > > So, I dunno, perhaps this is too simple or utility-ish, but it has the > potential to remove ~50 lines of boilerplate control/command line code, so I > thought maybe I''d send it in and see if it was interesting enough to include > in the distribution. > > (Also, I apologize if you''re getting this twice, but I sent this about a > week ago but from an email address other than the one I signed up to the > list for, so it likely did not go through. Since then, I have added a > -a/--standalone flag for easily starting the service_main/service_stop for > debugging purposes and thought I''d submit it again.) > > Thanks, > StephenThanks Stephen, appreciated. I don''t know if I''ll include it in the distribution, but I''ll post it somewhere on the project page. Regards, Dan