Yo once more,

maybe this is worth a few more words ... after Laurence's suggestion we 
spent some time here discussing ideas about it.  His suggestion solved 
two other nasty deployment problems for us.  Maybe useful for others.

1. my original approach was to have a generic 'lrms' python class, and 
then for each batch system have a subclass that implemented the generic 
methods via LRMS-specific actions.  The top-level script would be told 
which subclass to import.

The unfortunate consequence of this is that everyone who wants to 
implement the system for their LRMS has to know python, even if they 
already have something that does the same thing in another language.

My recommendation: don't use subclassing like this unless you are 
willing to write and maintain all the implementation-specific subclasses 
yourself.

2. the generic part of the ERT calc requires the inclusion of the 
generic lrms class.  However the LRMS-specific part is useless without 
this very same class.  Hence you get into RPM nightmares; do you have 
three RPMs (ERT framework, generic classes, specific classes) with 
interlocking dependencies?  It starts to explode rather quickly.

Using an ASCII file as an interface means that one could simply throw 
down the generic classes and ERT interface, and use something completely 
different (visual basic?) to write the LRMS-specific stuff if you want. 
  No complicated deployment-package dependencies, and no source-language 
dependencies either.  People with BQS tools in Ruby could write a simple 
converter to write out the information in the agreed ASCII format 
without ever looking at the Python.

Note that there is some code included in the ERT framework designed to 
detect intermediate files created by Perl scripts.  These are rejected 
with a fatal error.

	J "just kidding" T

Jeff Templon wrote:
> Yo,
> 
> One comment: credit where credit is due.
> 
> Tim Bell wrote:
> 
>> Jeff Templon took the same approach on the ERT by defining an
>> intermediate interface between the batch specific and the batch
> 
>  > independent parts.  This allows one side to follow the close evolution
> 
> It's true, I did do this, but the suggestion to do it this way
> originally came from Laurence Field.  It was a damn good
> suggestion.
> 
>                 JT