- Does the SCM record clients in its configuration when they are run? Probably not. How would it record the executable path, for example? We should find a way to make this more automatic.
- Provide methods to read/write SCM configuration.
- service_client --register #registers its configuration using above methods
- The above command can be called by waf during build to eliminate user intervention. The clients are already registered and ready for use upon installation!
- Can we rename the SCM's shutdown function to "kill" (and perhaps redefine its functionality) or something that can't be confused with xmmsc_service_shutdown?
- Can we change the default value of the "monitor" option (to check the configuration directory for updates) to true? This seems to cooperate much better with user expectations.
- Can we get rid of the "timeout" option (to wait before killing a service client after a shutdown request is received)? If we rename the method to "kill" its intentions will be a lot more obvious--take down the client now.
Wednesday, July 23, 2008
Next on the Agenda...
Well, the client-side of things is mostly done for now, so it's time I turned my attention to the remaining items. The server side of things needs to be updated/fixed and the service client manager (SCM) needs updating. The server is fairly straightforward, but I have some concerns about the SCM.
Subscribe to:
Post Comments (Atom)
1 comment:
All the information of a client is recorded in its corresponding scm config file. I was thinking that the client author should write that config file and ask the installation script (autotools, waf, etc.) to put it under "service_clients/" subdirectory in XMMS2 config directory when the client is being installed. The drawback of this method is that remote clients have no way to do this. But after all, SCM cannot launch a remote client.
The config file contains the path to the executable file, startup arguments and some other information which are all listed here.
The reason why the client author has to put all the descriptions of services and methods in the config file is that if the client is not running at the moment, the server will not have any record of this client's existence. So the user doesn't know what service clients are available.
Maybe it's better to delegate the task of reading/writing config files to SCM, instead of letting the installation script of the clients to deal with it directly.
When a shutdown request is received, SCM will politely ask the client to shutdown, giving the client a chance to clean things up and shutdown normally. If the time specified in the "timeout" configval has elapsed and the client is still running, then SCM will terminate it no matter what. If we always "kill" a client upon a shutdown request, then the client might not clean things up properly.
Post a Comment