[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dev-serveez] Avoiding code fork/duplication of serveez cfg code
From: |
Andreas Rottmann |
Subject: |
Re: [dev-serveez] Avoiding code fork/duplication of serveez cfg code |
Date: |
01 Dec 2002 15:47:26 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
stefan <address@hidden> writes:
> On 28 Nov 2002, Andreas Rottmann wrote:
>
> > However, I yesterday hacked up Serveez to make the configuration
> > mechansim more flexible. A short description follows, for more
> > information, see the patch and especially the changes to the
> > ChangeLogs.
>
> Hello!
>
> I had a short glimpse at the patch. Basically it looks good. Currently I
> am fixing the bugs you quenched in (found some memory leaks), brushing it
> up and adding proper documentation.
>
Thanks!
> This means your patch will be incorporated soon (with some modifications
> of course). Now my comments:
>
> > * svz_server_config_t is now named svz_config_accessor_t, however
> > svz_server_config_t is typedef'd to svz_config_accessor_t.
>
> Do you think it makes sense to put these accessors into the configurable
> type struct? Thus we would save some arguments to each function.
>
Well, I am not sure but I think the accessor is not really specific to
the type configured, but to the method the config data is extracted
from the `void *options' argument, so it *might* make sense to
instantiate the same configurable type with different `void *options'
and accessors.
> > * svz_servertype_t has now a member `config_prototype' of type
> > svz_config_prototype_t instead of `items', `prototype_start and
> > `prototype_end'.
>
> This is ok. Unfortunately it changes the ABI (so I also need to fix the
> serveezopt package).
>
Yes, I know, but I really could not avoid that.
> > So what does this gain us? A short use case should illustrate the
> > usefulness of the changes:
> >
> > [...]
>
> Didn't understand it yet...
>
> With the patch we do not gain too much for serveez right now since the
> functionality keeps the same. I guess with the new mechanism we could
> also configure port configuration (and thereby remove possible duplicate
> code)? Is this true?
>
Yes, that should be possible. I haven't looked into that yet, however.
> Can you please give a short example how you want to implement your
> 'services' and what will be the actual gain from the new functionality?
>
As I already explained, the whole thing came up during the
implementation of my DistWork project, which is a P2P load
distribution framework on top of serveez. It will have a 'prog'
service, that is able to execute a command and feed it with (one or
more) input and send back the output files multiplexing them over a
TCP stream. I want to configure the prog service like this:
(define-service! 'gcc-2.95-i386 'prog
'((executable . "/usr/bin/gcc-2.95")
(processes . 2)))
(define-service! 'oggenc 'prog
'((executable . "/usr/bin/oggenc")))
...
I hope you get the idea. Implementing this was trivial after having
hacked up serveez :-). So the new configurable type facility allows to
implement instantiation of scheme-configurable types with two lines of
scheme and a few lines of C:
------------------<snip>------------------
static int service_instantiate(char *type_name, char *inst_name, void *options,
svz_config_accessor_t *accessor,
char **err_msg);
/* define a new configurable type */
static svz_configurable_type_t service_cfgable_type = {
service_instantiate
};
/* add the configurable type before serveez reads its config file,
* for instance in a server global initializer */
svz_configurable_type_add("dstw-service", &service_cfgable_type);
/* This is the a function that instantiates a service. It's almost the
* same as server_instantiate in Serveez's server.c. */
static int
service_instantiate(char *type_name, char *inst_name, void *options,
svz_config_accessor_t *accessor, char **err_msg)
{
dstw_servicetype_t *stype;
dstw_service_t *service;
/* Find the service type */
if (NULL == (stype = dstw_servicetype_get(type_name, TRUE)))
{
if (err_msg)
svz_asprintf(err_msg, "No such service type: `%s'", type_name);
return -1;
}
/* Instantiate and configure */
service = dstw_service_instantiate(stype, inst_name);
service->cfg = dstw_service_configure(service, options, accessor);
if (service->cfg == NULL && stype->config_prototype.size)
{
/* FIXME: make svz_config_instantiate take an err_msg arg */
if (err_msg)
svz_asprintf(err_msg, "Unable to configure");
dstw_service_free(service);
return -1;
}
if (dstw_service_get(inst_name) != NULL)
{
if (err_msg)
svz_asprintf(err_msg, "Duplicate service definition: `%s'", inst_name);
dstw_service_free(service);
return -1;
}
dstw_service_add(service);
dstw_service_init(service);
return 0;
}
------------------<snap>------------------
When you have applied my patch to CVS, I can have look at using this
for the port configuration.
Regards, Andy
--
Andreas Rottmann | address@hidden | address@hidden |
address@hidden
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
- Re: [dev-serveez] Avoiding code fork/duplication of serveez cfg code,
Andreas Rottmann <=