Re: [dev-serveez] Avoiding code fork/duplication of serveez cfg code

[Andreas Rottmann]

Raimund 'Raimi' Jacob <address@hidden> writes:

> On 27 Nov 2002, Andreas Rottmann wrote:
> 
> hi folks!
> 
> > FYI: I now *have* started hacking away, so I'll soon be able to send
> > some patches against CVS for review. That should help to clear things
> > up ;-)
> 
> stefan and me discussed the issue briefly and we welcome patches.
> 
> two additional notes perhaps:
> 
> 1)
> did you have a look at SWIG ?
>  http://sourceforge.net/projects/swig/
> 
> i appreciate your efforts but SWIG might be what you are looking for...
> 
I know SWIG, but given the code in serveez, I think it's better to
generalize this a bit.

> 2)
> if you still want to go for the enhancement of the current code:
> i would really like to see the possibility of nesting structs.
> 
> that is, you make the mapper known structs of types 'A' and 'B' and later
> you introduce a struct 'C' that has an 'a_foo' value of type 'A' and 'A'
> in turn has a 'b_bar' value of type 'B'. this could be used in serveez to
> make 'portcfg' structs be a config item for servers more easily.
> 
Maybe I'll implement something like this, but ATM I have no need for
it.

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.

* I ripped out the config stuff from server.{c|h} and put it in cfg.{c|h}

* svz_server_config_t is now named svz_config_accessor_t, however
  svz_server_config_t is typedef'd to svz_config_accessor_t.

* svz_servertype_t has now a member `config_prototype' of type
  svz_config_prototype_t instead of `items', `prototype_start and
  `prototype_end'.

* You can register "configurable types" with
  svz_configurable_type_add(name, type) and instantiate them with
  svz_configurable_type_instantiate(name, type).

* There is a Guile binding for svz_configurable_type_instantiate:
  "svz:configurable-type-instantiate".

* guile_define_server() uses svz_configurable_type_instantiate().


So what does this gain us? A short use case should illustrate the
usefulness of the changes:

Say you want some arbitrary Serveez-based server to have configurable
entities (let's call them services).

What you now can do is:

* Add a configureable type with svz_configurable_type_add. The
  svz_configurable_type_t type struct specifies how to instantiate the
  type given a type name (a given configurable type may come in
  flavors, as the Serveez's servers do. Lets assume the new
  configurable type is named "service".

* Write a piece of scheme code to make defining new services easier:

(define (define-service! name type args)
  (svz:configurable-type-instantiate "service" type name args))

* Use `define-service!' (assuming that there is a `foo' service type):

(define-service! 'foobar 'foo 
  '((baz . "Hello World")
    (an-option . (1 2 3 4 5)
    ...)

The above code will translate the scheme alist into an option hash and
call the instantiate method of the configurable type.

Of course, I made `define-server!' use this mechanism as well. I did a
little bit of testing, and things seem to work, although I probably
have introduced some bugs.

I've attached the gzipped patch against CVS. The code is in no way
fixed in any way, I'm open for comments, so flame on :-). Of course
I'd like people to test this patch with their Serveez setups, it
*should* not really break anything besides ABI compatibility (of
course), if you don't explicitly mess with svz_servertype_t's config
members.

serveez-mods.patch.gz
Description: Binary data

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