On Jul 22, 2004, at 9:49 AM, David Parker wrote:

> The combination of perl and slonik seems pretty powerful to me, 
> allowing
> perl to do the procedural heavy lifting and leaving 
> replication/database
> operations to slonik. I think with a "little languages" like slonik
> there is always the point at which you want to start adding procedural
> constructs, more complex variables, etc., but it can be a slippery 
> slope
> and there is a potential to end up re-implementing a lot of
> functionality which was already available in standard scripting
> languages.

Well, I guess this is a fundamental development issue. There's a system 
that's designed to be extensible, but there's no accompanying 
specification of what methodology for extending it makes the most 
sense.

Clearly, there's a need for some sort of rule-based structure to 
manipulate slony. Does it make sense to create a separate rule system 
complete with parser to manage the manipulations? Well, slonik exists, 
so why not continue to develop it?

Alternatively, some pre-existing framework (e.g., Perl) could be used 
to manipulate slony according to a rule set. It could work in 
conjunction with a set of configuration files. Or, as seems to be the 
case now, manipulate configuration information stored in the database.

> The slony_setup.pl is certainly more monolithic than it needs to be, 
> but
> it's early days for this excellent project, and as a starting place it
> has been very helpful to me over the past few days, so I'm glad to have
> it! I would definitely welcome a set of more granular perl-based tools 
> -
> maybe eventually a perl interface to slonik?

Right, so which makes more sense? A bundled distribution of tools for 
slony users based on what developers and users agree makes the most 
sense in terms of functionality? Or a slony API that is distributed 
with the daemon, where users are responsible for writing 
slony-compatible applications to configure their replication 
environments appropriately.

I would be more interested in slony_setup.pl if it didn't make 
assumptions about my environment or allowed the assumptions to exist as 
defaults that could be overridden.

> As far as configuration/build of slony itself, I would wonder about
> moving away from configure, etc., just because it is used in so many
> projects, most importantly postgres itself, of course, and people are
> used to it.

Yeah, I think configure makes sense for basic options, but I don't 
think configure is going to handle (or should handle) all the issues 
above.

-tfo