> We might want to break slonik into two pieces. An API that contains any > of > the required set setup, locking logic etc. This API could be used by > multiple admin front ends (slonik, pgadmin, SlonEM..). And a command line > processor that provides a similar interface as slonik currently provides.
I fairly strongly disagree. Keeping slonik stable is very important because there's code out there that depends on how it functions now. What would make sense would be to create something new. > I don't think this would be that hard to divide slonik in this fashion the > code is mostly divided like that anyway. Writing a Perl module wrapper > that exposes the API shouldn't be that difficult either (I suspect the > same > could be done for tcl). Would that make the altperl tools easier to > maintain? I think this requires creating a new set of Perl tools, because using the API (that is, in truth, already there; pgAdmin uses it...) would require opening multiple connections and introducing DBI to the mix. The design of "altperl" has *very* consciously left DBI *out*; it consciously *does not* interact with the cluster (with a couple of inconspicuous exceptions). I would argue against quietly messing with "altperl." I think it would be a bad idea to try to quietly evolve altperl into something else. At some point, that leads to a very painful change of understanding of what it is, and some serious disputing over that. It seems to me that it would take a fairly considerable redesign to create a "PerlNG" set of tools that themselves embed some of what is presently implemented inside Slonik. But I think that's the better answer. If you want something completely new, create a new thing. _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
