[xen-tools] Re: More changes

[Steve Kemp]

Hi,

  Sorry for the slow reply, especially after my previously
 harsh mail.  I'm pretty busy at the moment, which almost
 certainly contributed to the tone of my previous mail.

  I'm sorry if I overreacted, or was percieved more hashly
 than I intended.  I genuinely welcome contributions, and
 I'm usually happy to be persuaded on issues if there are
 two or more approaches and people dislike mine.

  That said I'll now summerize how I view things at the
 moment.

  In my opinion xen-tools is a collection of related tools
 which may be used to create and manipulate Xen guest domains.
 Nothing more, and nothing less.

  Because the tools share a lot of common code/ideas I'd
 like to modularise them somewhat.  This is where I think
 our ideas have the possability of coinciding.

  The only significant difference between my thoughts and 
 your proposed design is that I regard the modularisation
 as primarily an *implementation detail*.

  I find it hard to picture a situation where users would
 want to use modular library code to create their own guest
 domains on demand, then later remove them.  This is for
 two primary reasons:

     1.  It ties them into using Perl, which many external
        programs/projects do not.

     2.  It involves them writing code for little appreciable
        gain.  (ie. customisation can be substantial right
        now via both the skelington system & the hook solution.)

  So I believe that for 99% of cases the command line tools
 themselves, and their associated command line arguments reflect
 the public API.  (Indeed I am aware of several applications,
 some public and some not, which *do* create and destroy 
 Xen guests by essentially running fork()/exec("xen-creat....").)

  I, personally, would like to refactor the core of the code
 such that there exists both:

  1.  A binary directory containing the xen-create-image, etc, scripts.
  2.  A library of modules/modular code which is shared between them.

  With that in mind the choice mostly falls down to being
 how to organise the modules.  Right now I have a list of
 hardwired installation methods, for example, which would 
 be nice to extend via inheritance of an abstract "installer"
 class.

  Similarly it should be possible to abstract the different
 storage mechanisms, (loopback, lvm, evms, drdb), into a
 clean hierarchy.

  Right now I've neither planned in a serious way, nor
 implemented any such thing.

  (Although you can see hints of my thinking if you look
 at the recent updates to use --install-source + --install-method
 rather than the tool-specific flags which were previously
 in place.  The reason for that?  A proprietry installation
 method which uses an "image-server".  Neat.  I may be able to
 discuss this, or share the code at some point in the future
 but not yet.)

  Anyway I'll stop here for the moment; I just wanted to
 reply quickly to explain myself, apologise for being
 harsher than intended, and to avoid leaving people in 
 suspense.

Steve
--