Provide a standard location for user-developed scripts to live in

[GoogleCodeExporter]

1. To which tool/application/daemon will this feature apply?

Tungsten Replicator

2. Describe the feature in general

Users need a safe location for locally developed filters and batch load 
scripts.  For example, it is common to edit hadoop.js to set the location of 
staging directories or to add extra bells and whistles like compression.  These 
should be stored in a way that allows them to live through 

We will provide a standard directory for such scripts with a simple mechanism 
to find the scripts.  The canonical use case to support is enable users to edit 
hadoop.js.  If the user edits hadoop.js, he/she can put it in safe location 
that does not vary as a result of upgrades.  If such an edited copy exists, we 
use it, otherwise the installation uses the normal hadoop.js. 

The mechanism in question should work with filters as well. 

3. Describe the feature interface

This will be determined. 

4. Give an idea (if applicable) of a possible implementation

It would probably be simplest to use a search path mechanism.  Unfortunately 
the samples directory is quite disorganized overall.  One option is to apply 
this only to the extensions directory and move things that require search path 
support to live under that directory.  This would require moving the 
scripts/batch directory to something like extensions/mergescripts. 

5. Describe pros and cons of this feature.

5a. Why the world will be a better place with this feature.

Enables users to maintain stable additions to the replicator. 

5b. What hardship will the human race have to endure if this feature is
implemented.

This may require some restructuring of existing scripts to implement cleanly. 

6. Notes

See also Issue 907. 

Original issue reported on code.google.com by robert.h...@continuent.com on 15 May 2014 at 10:16

[GoogleCodeExporter]

Additional requirements: 

+ This must be a location independent of the main structure so that the 
contents can survive during an upgrade without the scripts having to be 
explicitly copied. 

+ Structure should be flexible enough to support scripts of multiple types to 
enable scripts for different purposes to be supported, in particular, scripts 
for filters, batch loading and database engine specific settings or 
customisations. 

Original comment by mc.br...@continuent.com on 16 May 2014 at 8:08