[Mono-list] System.ServiceProcess.ServiceBase
A Rafael D Teixeira
rafaelteixeirabr@hotmail.com
Wed, 09 Apr 2003 11:07:52 -0300
>From: Mark Derricutt <mark@talios.com>
>If it compiles fine, it should suffice for what we currently need ( with
>it still running on a windows host ). I'll take a look a the services
>stuff in cvs, not sure if I'll be much use thou, so far I'm only a week or
>two into really using C# :)
I've made minimal stubbing, so just pointing non-stubbed parts you need is
of some help. Testing implementation, when done, is also helpfull, so please
don't think you can't help. Thanks for any help!
>What sort of services framework do we want to provide to mono/linux? We
>were discussing this in the office this afternoon, possibly implement the
>ServiceBase class to provide base functionality that'll fork and daemonize
>itself, and handle ( pass over to the implementing subclass ) the
>appropriate start/stop/restart messages ( kill -HUP or process.exe
>--restart style ).
Sure that is one way of doing things, but my proposal is to have a single
daemon (I'm calling it 'monod') starting/tracking/managing all mono
services. Somewhat similar to services.exe in Win2000, that manages
services, each one started in a svchost.exe process.
The monod daemon would be started in the SysV style. But each service would
be started on a dedicated process created by monod (no need to fork itself).
The advantages of this approach are:
- Services configuration semantics (start on boot, start on-demand, start
manually) are more easily mapped to any platform. The Linux way would demand
coordinating rc files/directories with inetd/xinetd. Also inetd only can
start services on demand if they listen a tcp port, what isn't always the
case (I'm surely not a Linux expert, so I may be wrong here)
- A GUI for starting/stopping services is easier to construct by talking
directly to monod than having to read/interpret scattered files (etc/conf,
PIDs, etc...)
- Pausing/restarting services could be faster. It obviously depends on the
chosen communication channel between monod and the services, but we need a
fast one anyway.
- Security settings (impersonation issues specially), would be easier to map
and control, and would behave more like .net security.
And so the list would go on...
Hey, people in the list, what are your thoughts?
Happy hackings,
Rafael Teixeira
Brazilian Polymath
Mono, MonoQLE Hacker
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail