dev-serveez
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]