Re: [Gnu-arch-users] Low level vs. high level UI

[Pierce T . Wetter III]

> >    Yeah, what I really meant is "pooled their efforts, and 
> > documented".
> > aba is distributed with tlacontrib, but its not really integrated.
> >
> >   In tlacontrib, you have aba, which is kind of a front end for tla 
> > that
> > implements some handy stuff like aliases (but has super minimal
> > documentation, I had to browse the source to find out I could do aba
> > help command),
>
> It says "Use aba command -h for help on `command', or aba help command
> for detailed help" at the bottom of "aba help" output.  But it's just a
> frill-- aba command -H still works too.

 Sure, but README doesn't mention any of that...

 Really, you could bootstrap some documentation by just dumping aba 
help, and aba help command for each of the aba comands to a file.
> >   So it seems to me like aba is a good building block, and should
> > subsume some of the tla-contrib scripts and some of the tla-tools
> > scripts, and eventually become the "thing you run instead of tla,
> > unless you want to do something weird".

> I think we should wait until tlacontrib ships with tla before we
> consider declaring aba some kind of official interface for tla, though 
> I
> appreciate the vote of confidence.

   Ok. :-)
> >   But again, I'm a GUI developer, not a nuts-and-bolts guy, so I 
> > prefer
> > high-level interfaces. Perhaps you do too, which is why you wrote aba.
>
> I prefer easy interfaces, not simple ones.  For example, I use vim.  
> And
> I can use aba exactly the way I use tla.

  The difference between an easy interface and a simple one? I'm not 
sure I understand the distinction? I prefer levels of interfaces 
myself.

> >   What I think is that if you all sat down together and brainstormed a
> > bit, you could come up with a vastly simplified interface to tla, and
> > implement it in aba.
>
> My view is that gradual evolution is a more certain way of generating a
> set of useful commands than high-level design.

  Both have their place. I think its sometimes good to sit down and 
think:

   Ok, what do I do all the time in arch?
   How could that be more automatic?

   What do I do rarely enough that I forget how to do it?
   How could I make that easier/more interactive

> > You'd probably have to make some assumptions about
> > the BEST(TM) way to do things (or have some way that users could
> > specify their preferences), but people could hit the ground running
> > with arch.
>
> Actually, I think you'd need a different kind of scripting, e.g.
>
> foo$ tla-setup
>
> Setup for Tom Lord's Arch
> =========================
>
> Please enter your full name: Aaron Bentley
>
> Please enter you email address: abentleypanoramicfeedback.com
>
> That doesn't appear to be a valid email address!
> Please enter you email address: address@hidden
>
> ID created!
>
> Please enter a directory where tla can store data
> [/home/abentley/.tla-storage]:


 While that might be good, its not so much that, as I think that there 
are a common set of strategies people use for using arch, and that's 
the things I haven't learned yet. The multitude of low level commands 
end up obscuring that for new users to some extent.

 For instance, how do you decide with id strategy to use?


> >   Something like that is inevitable really, its just whether it would
> > happen soon, or later. I'd rather it happened sooner, because I'd like
> > to see all this arch knowledge move into code, so that I can have a
> > small set of "aba" knowledge instead of a large set of "arch"
> > knowledge.
>
> I agree that tla's large command set represents a fairly high barrier 
> to
> entry.  On the other hand, I only use about 7 commands 95% of the time.
> I'd like to see a tla HOWTO document that gets you started with a good
> setup, rather than trying to explain all the choices.

 Ah, what are the 7 commands you use. I'd like that HOWTO document too.

 The current documentation isn't really a good jumpstart, unless you 
use it in the central repository mode, which no one does...
> >   Pierce
> >
> > P.S.
> >
> >    aba suggestions:
> >
> >    have a register-archive that both registered the archive, and built
> > an alias:
> >
> > aba register-archive jblack address@hidden
> > http://arch.linuxguru.net/~jblack/{archives}/2004
> >
> > would let me use
> >
> > ^jblack for address@hidden
>
> I tend to use aliases for fully-qualified version names, e.g.
> address@hidden/tlacontrib--devo--1.2, so that
> would not be useful for me.  But if you'd like to write it,
> contributions are always welcome.

  If I knew arch a little better, I would...

> >   In the big picture, aliases are a general high-level facility so 
> > that
> > aba users can work with much shorter names. I would think that aliases
> > should be names that they tend to create as they go along with other
> > aba commands like "branch-this" and "tag-this".
>
> Oh, I almost always branch into the default archive.  So I haven't seen
> the need for it.  How would you use it?

  Well, like if I wanted a branch:

   projects--fixingpunctuation--1.2 in archive:


  aba branch-this fixingpunctuation

  would let you use

 aba get ^fixingpunctuation

 because that would expand to:

 tla get address@hidden/projects--fixingpunctuation--1.2

 Does that make a little more sense? The idea is that you could give 
short names to aba, and then reuse them later.

 Pierce

smime.p7s
Description: S/MIME cryptographic signature