Le Thursday 06 March 2008, Christopher Browne a écrit :
> "lio bod" <liobod.slony at gmail.com> writes:
> > Thx for the fix.
> >
> > I havn't test the last HEAD release yet. I 'm afraid i won' t have any
> > time for this by now.
> >
> > The generated *.slonik files helps me as sample that i modify with my
> > little hands...
> >
> >  
> >
> > Btw, the store_paths.slonik file looks weird :
> >
> >  
> >
> > STORE PATH (SERVER=1, CLIENT=2, CONNINFO='dbname=mydb host=myhost1
> > user=pgslony port=5432'); else STORE PATH (SERVER=1, CLIENT=2,
> > CONNINFO='dbname=mydb host=myhost2 user=pgslony port=5432'); STORE PATH
> > (SERVER=2, CLIENT=1, CONNINFO='dbname=mydb host=myhost2 user=pgslony
> > port=5432'); else STORE PATH (SERVER=2, CLIENT=1, CONNINFO='dbname=mydb
> > host=myhost2 user=pgslony port=5432');
> >
> >  
> >
> > and i'm not really estonished by error produced :
> >
> >  
> >
> > $> slonik store_paths.slonik
> > store_paths.slonik:2: ERROR: syntax error at or near else
> >
> > another bug or wrong use?
>
> Hmm.  That's the same sort of bug that you pointed out before, in
> another spot.  I'm not sure how that broke in version 1.2.
> Conceivably a cut'n'paste problem?
>
> > I go on on with with some idea of improvement even if i guess they
> > are so obvious that they might already be in your roadmap :
> >
> > - why not separate files among thiner functionnality : 1 file
> > *.slonik file for creating cluster, another for nodes, another for
> > set, another for tables, another for sequences , ..., what else?,
> > and subscription
>
> The purpose of the script was to configure replication fairly simply.
> I'm not sure I want to add every conceivable bit of extra
> functionality.
>
> > - why not produces undo *.slonik files (with same granularity) :
> > remove subscription, ..., untill remove cluster (even i still not
> > sure of my self how to make so with bare metal).
>
> Why not?  Because that doesn't fit with the name:
> configure_replication.sh.
>
> I don't want to complicate it for the sake of complicating it.
>
> We already have the whole set of "altperl" scripts that have grown
> challenging to support because:
>
>  1.  A lot of the "mature users" find it simpler to go straight to
>      writing slonik scripts.
>
>  2.  The "altperl" scripts have grown to require a pretty
>      sophisticated set of Perl data structures to describe clusters,
>      which require that the users do some sophisticated reading,
>      and nonetheless, the scripts make a whole lot of simplifying
>      assumptions about the "shape" of the cluster, and therefore
>      aren't anywhere near "fully general" in being able to express
>      all the sorts of things that someone might want to do to a
>      cluster.
>
>      (Notably: if you have a pretty complex network structure, Slony-I
>      can cope with this, but "altperl" has no way to represent that.)
>
> I'm not sure what to do with/about the "altperl" tools...  They get
> just enough "patch" attention from users that it would seem unjust to
> deprecate them, but they aren't being really properly maintained, all
> the same.  I decline to be the "proper maintainer;" if there isn't
> enough community interest, I think they *should* get deprecated.

Slony release when main devs think it is time to do, and as you said, 
perltools are not maintain by core-dev. 
I find them usefull for my first approach of slony and wish them to keep 
up-to-date, or *at least* to be sync with a specific release. So, looking at 
the slony 'roadmap', perhaps it can be better to push tools scripts to 
another place : a pgfoundry or a slony-tools-1.2.X.tar. 
Then, it let 'mature users' get the core, and other users get the 
contrib-tools wich are *sync* and released with slony versions.

I prefer have to wget slony-1.2.13, slony-doc-1.2.13, slony-tools-1.2.13 
archives, but be sure they work all together. Than getting one package with 
doc from 1.2.12, tools between 1.1 and 1.2.12 and core from 1.2.13.

It can consolidate them by releasing each part singly (even if at the same 
time).

Views ?


>
> I think I'd prefer to keep "configure_replication.sh" on the simple
> side, so that it's clear that it's a "crutch" to help, as opposed to
> trying to make it the "comprehensive solution" that it really can't
> be.



-- 
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.slony.info/pipermail/slony1-general/attachments/20080307/523598ff/attachment.pgp