Log Message:
-----------
Removed the generate_listen_paths item and discussion, since it has
been implemented.

Added the following:

- The scripts are currently not compatible with "use strict".  They
  would probably become easier to follow if they were (particularly
  with regard to figuring out where variables are defined).

- We probably don't need one script per slonik command.  Which of
  these can be combined, preferably without having to implement pages
  of arcane command-line options.

- slon_start, slon_kill, and possibly slon_watchdog should be made
  into a slon_ctl shell script, with an /etc/init.d-compatible
  wrapper.

Modified Files:
--------------
    slony1-engine/tools/altperl:
        ToDo (r1.2 -> r1.3)

-------------- next part --------------
Index: ToDo
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/tools/altperl/ToDo,v
retrieving revision 1.2
retrieving revision 1.3
diff -Ltools/altperl/ToDo -Ltools/altperl/ToDo -u -w -r1.2 -r1.3
--- tools/altperl/ToDo
+++ tools/altperl/ToDo
@@ -6,77 +6,25 @@
   with the configuration actually found on some node, add "additional"
   bits, and drop obsolete bits.
 
-- It would seem likely that the function "generate_listen_paths()" in
-  init_cluster.pl would be beneficial to port to pl/pgsql, as
-  there presently isn't any capability to rebuild the listener
-  paths by automatically dropping the old ones.
+  [Note: If drop_node and store_node are used, this may not be as
+  immediately necessary, but would still be nice to have.]
 
 - At present, the configuration generated by this set of tools is
   fairly fragile.  If just about any sort of error is made, it is
   commonly needful to drop all of the Slony schemas, thereby cleaning
   _everything_ out, and restarting the configuration process from
-  scratch.
-
-  That certainly isn't ideal.
-
-
--------------------------------------------------------------------------------------------------
-
-More about the "generating SET LISTEN" calculation
-------------------------------------------------------------------------
-
-I have been mulling over the notion of setting up the Slonik STORE
-LISTEN(ORIGIN=a, RECEIVER=b, PROVIDER=c) configuration via a stored
-procedure, using in-the-DBMS data.
-
-The "features" of this idea:
-
-This involves having a table (view?) containing the intended parentage
-for each node, that is, which nodes point to which parents.
-
-This would allow the following good things:
-
-- Can't drop a node that has children, probably adding in other
-possible data checks
-
-- Can calculate the full "listener matrix" within pl/pgsql instead of
-doing it in Perl (take a look at init_cluster.pl, subroutine
-generate_listen_paths()).
-
-My preliminary thinking about it was pointing to there being a pretty
-elegant way to do this using SQL queries that might be more readable
-than the dynamic programming formulation embedded in that subroutine.
-(I didn't write out the Bellman equations, but took a look back at my
-old optimization texts ;-).)
-
-The primary problem that this solves is to create those STORE LISTEN()
-definitions, which get pretty involved to generate by hand if you get
-more than three nodes.
-
-In doing some further thinking, I noticed a couple of conspicuous
-challenges:
-
-1. There can be no fixed association with sets, as the sl_listen table
-does not contain set fields, and different sets can use differently
-shaped subscription trees.
-
-(I think users would be doing something pretty stupid to have _wildly_
-different arrangements for different sets, but I still have to support
-it...)
-
-2. The tree cannot be based on subscriptions because it needs to exist
-before any subscriptions are established
-
-In effect, I have no fixed place where I can get the information at
-the point at which I most need it.
-
-Once all nodes are subscribed, I could use subscription information to
-weight the cost functions, but I need the data BEFORE we do anything.
-
-This isn't pointing yet to a good approach to "seeding" it; if someone
-has some inspiration, let me know...
--- 
-Christopher Browne
-<cbbrowne at acm.org>
-
--------------------------------------------------------------------------------------------------
+  scratch.  That certainly isn't ideal, and is partially preventable
+  by proofreading the slonik scripts before running them, but more
+  robust error-handling (and prevention) would be welcome.
+
+- The scripts are currently not compatible with "use strict".  They
+  would probably become easier to follow if they were (particularly
+  with regard to figuring out where variables are defined).
+
+- We probably don't need one script per slonik command.  Which of
+  these can be combined, preferably without having to implement pages
+  of arcane command-line options.
+
+- slon_start, slon_kill, and possibly slon_watchdog should be made
+  into a slon_ctl shell script, with an /etc/init.d-compatible
+  wrapper.