[Top][All Lists]

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

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

From: Pierce T . Wetter III
Subject: Re: [Gnu-arch-users] Low level vs. high level UI
Date: Wed, 25 Feb 2004 09:51:27 -0700

 In order for arch to be accepted more widely, it has to have a much
smaller learning curve. The easiest way to do that is to have some
high-level commands that do the main tasks users actually do, with the
low-level commands left for the special cases.

I strongly agree.

I'd add a perhaps more subtle point: Tom says that 3rd-parties can
address this, which is true - and they do.

But there is something to be said for a canonical interface. Canonical,
"blessed" interfaces are attractive for a number of reasons, not least
that they are more likely to receive attention during development and
are less likely to become broken through neglect.

Also, right now arch is self-selecting for people comfortable with low-level interfaces, so the likelihood of the 3rd parties doing this is low...if you want GUI geeks like me to write interfaces, you need to first have a high-level command line interface.

Really, I suspect if the aba, tla-contrib, and tla-tools guys just pooled all their stuff, we'd have a good start. They just don't seem to be doing that, and their documentation is kind of sketchy.

Also, the high-level interface ends up driving features in the low-level interface so they are really siblings.

  So anyways, "someone else is going to do that" doesn't really work.

In the hope of contributing to getting better commands merged in, I
plan to do what might be a very small thing but hopefully nonetheless
a useful thing - a comprehensive page or three on the wiki, listing
every possible tla command and extension, with a short summary - one
page listing them in lexicographical order, and one sorted by category.
This will make it easier for everyone to see what's available,
hopefully - and maybe even promote better consistency.

That would be good. The Arch Recipes help somewhat too, though I kind of wished they were a little more explicit about what's going on. Like if they explained why they were constructed that way.

    bootstrap a project into arch
       How do you move a project into arch? Start with a simple project
       move onto nested projects, then onto config files.

    when to make archives, mirrors
       I've sort of picked up by osmosis that people tend to make their
       own personal archives of their work, and mirrors of central
       repositories but I don't understand how they decide why, when.

    branching & joining

       What are the common ways that people end up doing branching?
       Does this depend to some extent on how you like to setup your
       archives and mirrors?


       How do you do parallel development


reply via email to

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