> > We can always have a `monoservices' init.d script for the SysV to > > launch, and this one in turn would load the definitions for Mono > > services from a Mono-controlled directory, but that way we minimize the > > integration work, and maximize flexibility. > > I'm also voting for the mono based service manager. Additionally to the > compatibility issue I could imagine that we also would gain some > efficience from using a mono based service manager: See the Mono runtime > would be launched only once (potentially faster startup) and as long as > not explicitly requested to deal it different all the services could > life in appdomains of the same mono vm... > > Ciao, > Mathias
Yes, doing it this way is infinitely preferable. Once you have a general mono services manager (msm) that handles ordering itself and allows you to control individual scripts, it becomes a packaging/distribution problem of how it gets loaded. Each service can even be individually integrated into the SysV startup process, provided the msm can provide an in-order list of services. A little scripting magic could generate the proper symlinks/commands to add the services to whatever the platform standard service system is, or it can be run to just start all of the services itself, whatever fits the system. -- Shahms E. King <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
