Josh Berkus wrote:

>Chris, Steve, Darcy,
>  
>
>>databases; they are consciously loosely coupled so that they can "play
>>well" in environments where you get Perl provided but where you _can't_
>>add extra CPAN modules.  In particular, I am thinking of the UNIX(tm)
>>systems: AIX, Solaris, HP/UX, and such.  We're running AIX and Solaris
>>in hosted environments where we don't get to install extensions, and
>>Pg/DBI would be examples of extensions.
>>    
>>
>
>Interesting.  I was about to suggest building altperl as a CPAN module, in 
>fact.  Now I can see how that might not be desirable.
>
>  
>
It perhaps would have been more obvious if I had written the scripts in 
Awk+Bash, which are more conspicuously "lowest common denominator" 
(LCD).  It's a bit unfortunate that it's so tempting to extend any Perl 
application by linking in great gobs of CPAN extensions...

>I can see the desire, eventually, for 2 sets of tools: 1 in altperl which is 
>loosely coupled with no dependancies other than slony, and one as a CPAN 
>module that makes use of DBI, Introspector, ps and other modules.
>
>  
>
Surely.  I think it's an excellent idea to add further tools that may do 
more or less sophisticated things via adding in whatever extra CPAN-like 
things you may want.  I'll cheer; I'll check code in.

But for some "base set," I will remain partisan for the "LCD" position.

>For the cluster information file, I'd suggest some simple, human-readable, 
>XML.  We don't want to get into the trap of needing additional tools just to 
>eyeball the configuration file.  The structure of a cluster suits itself well 
>to the nesting inherent in XML.   The drawback to this idea, of course, is 
>the requirement for at least one XML module for Perl.
>  
>
Oh please, no.

The present ".nodes" scheme presents the configuration as a bit of Perl, 
which is readily checked out for syntactic correctness by typing in:
% perl my-node-info.nodes

Nothing special is needed to eyeball that; depending on your text 
editor, it may merely take some sort of "electric tab" to reformat it 
into being pretty again.

Introducing an XML format would be anything but lightweight.  It _might_ 
be attractive if there were programs in 4 languages trying to 
simultaneously parse the files, although at that point, I think I'd 
rather have them standardize on using libpq to query the Slony-I cluster 
directly, as that is ultimately the "authority" on what the cluster 
looks like.
-- 
<http://linuxdatabases.info/info/slony.html>