On Fri, Jul 29, 2005 at 03:25:04PM +0100, harry wrote:
> I think you should move towards a model where the tools dynamically
> discover the available configuration commands from components which are
> installed in the system such that the tools eventually contain no
> command specific code at all.
>
> For example, on installation, the balloon driver might register itself
> as a configurable component which provided a single configuration action
> called (for the sake of argument) resize. When the balloon driver was
> installed in a domain, the configuration tools would discover the
> balloon driver as a new configurable sub-object belonging to the domain
> and query the registered configuration interface to discover the resize
> method, the help text, the parameter types and the valid parameter
> range.
>
> Subsequent invocations of xm-help would list the domain-balloon-resize
> method with an indication of the parameters and help text.
>
> A mechanism like this would allow 3rd parties to extend the system
> without having to modify the low-level configuration tools. Having the
> entire specification and implementation of the configuration interface
> in a single location (in the example, the balloon driver code) also
> makes it easier to avoid incompatibilities between the tools and
> configurable components since there is less coupling. In fact, the level
> of coupling has been shifted from the component specific details of the
> configuration interface to the component-independent aspects of the
> mechanism for specifying interfaces.
>
> I think this would naturally tend towards an object-verb form of
> expression since this would be consistent with the discovery process.
>
> Harry.
I actually think this is exactly the opposite from what we want, and is
actually what is in there now and makes it such a mess.
Let's look at xm help, for instance. In order to run xm help, which you
think would be simple, you have to import about 10 objects for every feature
that xm could possibly support, if any of these fail you die. Then you need
to instantiate classes for every sub command, if any of these fail, you die.
Then you run through each object, figure out what group it is in, pull help
from each object, and stick that together. If anything fails here, you die.
The real rub is that those 10 imported objects, all import their own
objects, etc. If any of those fail, you die. A really good instance is
"why can't I run xm help as none root?". Because xm needs write access to
the xend log files (buried about 5 object imports down). You can't seperate
that out in any reasonable way to check permissions upfront. You can't move
the imports into main() to trap there, because all the 20 classes for each
command expect those objects to be global in main.py to operate on them.
So lets say you end up with a model where you *can* catch each object
failure, what do you do? Do you quietly turn off/on options based on what
is there? That means the interface of xm would change day to day. I'd hate
to have to answer support questions on that. :)
While quite interesting from an engineering elegance point of view, it is
quite problematic from a user point of view. xm help should provide the
same set of options this morning and this afternoon, unless I very
intentionally upgraded the program. Additionally the future architecture is
really centered on xenstore as the management interface. I don't think
integrating every possible usage of xenstore into xm/xend is the right
approach.
I think this needs to take a much more user centric, Model-View-Controler
approach. Forcing the User Interface to be a direct reflection of how we
happen to have objects underneath usually just causes no end of usability
(and maintenance) pain.
Such is my 2 cents.
-Sean
--
__________________________________________________________________
Sean Dague Mid-Hudson Valley
sean at dague dot net Linux Users Group
http://dague.net http://mhvlug.org
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
pgpWfWgKRNtBL.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home