gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Announce: axp - a new command line tool


From: Mikhael Goikhman
Subject: Re: [Gnu-arch-users] Announce: axp - a new command line tool
Date: Fri, 29 Oct 2004 23:22:18 +0000
User-agent: Mutt/1.4.2.1i

Please convince your mailer to never wrap quotes. It is hard to read.

On 30 Oct 2004 06:39:19 +1000, Zenaan Harkness wrote:
> 
> On Fri, 2004-10-29 at 01:56, Mikhael Goikhman wrote:
> > 
> > axp features a multi-level pluggable command set. This means the
> > command namespace is not necessarily flat. I would not start to
> > discuss the merits of both approaches (i.e.
> > "tla library-add|library-remove" versus "tla library add|remove"),
> > but I believe the multi-level subcommand system makes quite a sense
> > when implemented properly.
> 
> Very nice. I like this a lot.

I think the flat command system has its strengths, i.e. easy to
implement, easy to understand. But then again, it may be as well hard
to maintain (one big switch) and hard to understand (lots of commands).

I implemented the multi-level for two reasons. First, axp is intended to
be a multi purpose tool. So if one day someone wants to add the PQM
functionality, he adds one command "pqm" on the main level and hides its
actual interface (i.e. "pqm submit", "pqm process", whatever). Good if a
user is not interested in PQM, or on the contrary only needs PQM.

The second reason is implementation specific.  axp is modular, one
command is one module, so we have 100 modules for 100 commands. The way
it works is on any "axp partners add" command exactly 3 modules are
loaded: axp, axp::partners and axp::partners::add, each next one is
inheriting from the previous. So all commands inherit from axp (thus
you have generic --help and help support). The actual common partners
functionality may be done in axp::partners, and so on.

> > All commands are automatically provided with the "--help" option, and
> 
> And -H ? Is there any reason to not support "standard tla" options?

I don't see a need to have -H, since -h does just this. Also, the option
parser I use is configured to ignore the case, for simplicity.

> > composite commands are automatically provided with the "help"
> > subcommand. This "help" subcommand by default lists one immediate
> > level only, unless called with --recursive option, so the help
> > output is usually short.
> 
> That's great.
> ...
> > Question: Is axp a competitor of fai and xtla?
> > 
> > Answer: Not exactly, the ideology is a bit different. Unlike these
> > tools, there is no intention to replace tla and a shell.
> 
> why not replace? why not be a full front end? or are you just deflecting
> potential short-term criticism as axp functionality grows? I think this
> will be a very nice structure for command line use of [lib-]tla.

There are just too many reasons for this. In no particular order:

  * I am mostly happy with tla, and very happy with the shell
  * I don't really want to step on the Aaron's territory just because
    I think I have a better technology; he is a significant arch expert
  * I have other arch related projects, no time for everything :)

Anyway, the axp framework is pretty good and I will very slowly work
on adding more useful commands. Contribute if you want it earlier.

> BTW, I recommend changing the command to apx if possible

The first feedback I got was how "axp" is a bitch to type on Dvorak.
Are you people serious or what? :)

Regards,
Mikhael.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]