On Mon, 12 Feb 2007 17:43:50 -0500, Mark Stosberg <[EMAIL PROTECTED]> wrote:
[...]
>
> 1. The single, central config file. Even if there are options that are
> set per-node, it's still nice to have everything in one config file,
> perhaps with an "include" directive to handle complex setups.
Include seems a nice idea. However, i think what we need is a clean, easy to
maintain
and easy to use interface, too, nothing than current which spreads
implementation over
half a dozens of scripts. It works, but i think a better way is to modularize
most of the functionality into special classes which do the interface for
accessing
the slony functionality for us (see my idea below).
>
> 2. No raw slonik or custom scripting needed for common commands. For the
> basic master/slave setup, altperl has been a complete solution for me.
>
That's the point. The altperl scripts are heavily used by people around here,
even for learning purposes. Improving that is a natural consequence...
> Stepping back, as a new user, the various interfaces and layers have
> been confusing, especially:
>
> 1. slon.conf vs slon_tools.conf
> 2. 'slon' vs 'slonik' vs "slony" vs "slonik_*"
>
> It would be nice to bring some simplicity here. It seems like a a future
> "slon.conf" could merge in the functionality that "slon_tools.conf".
I even though about XML to "describe" a cluster, but we need then to carefully
design such a beast...and to merge semantics together.
> I see that binaries better named as:
>
> slon -> slond
> slonik* -> slonc (with subcommands..."c" being for "client")
>
> Anyway, the names themselves are not the most important thing, but the
> quality of different but similar names is.
>
> Are others interested in continuing to have a higher-level interface
> that doesn't require using slonik directly for common operations?
>
I recently started to think about an Object Oriented "easy-to-use"
altperl-library
which implements most of the functionality embedded into a single perl library
which
could be used in a clean, distributable manner. I've done a first prototype
named
SlonConfig.pm which implements a class for configuring, administering and
monitoring
of a slon cluster, but it's nothing more than a prototype for now. What i could
imagine
is an interface like
$conf = SlonConfig->new(<params or config of cluster>)
$conf->addNode(<node>);
$conf->getStatus(<cluster>);
$conf->subscribe(<params of set>);
$conf->move(<params>);
Each instance of such an object would describe a cluster configuration and
would provide
an easy interface to the underlying infrastructure (maybe the same way as
altperl currently does
by generating slonik-scripts), for example
slonc --subscribe 1 2
slonc --createset 1
slonc --failover node1 node2
etc...
I really would like continuing to work on that and to share ideas, Mark,
maybe we could coordinate efforts?
Bernd
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
