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

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

Re: [Gnu-arch-users] Features command for arch


From: Tom Lord
Subject: Re: [Gnu-arch-users] Features command for arch
Date: Thu, 2 Sep 2004 10:56:43 -0700 (PDT)

    > From: address@hidden

    > > Ok, suppose that we accept that.... that still leaves the question of
    > > what *is* the "features" feature?

    > I would see it as a kind of database bound to this specific instance
    > of the application (but see below), providing some introspection.

I like the word "introspection" here.   That *is* (i agree) the key
thing.

Whatever `tla features' winds up doing --- it is (in its platonic
ideal) that instance of `tla' making true assertions about itself
("introspection").

We have some rough ideas so far such as:

  ~ sub-command CLIs change over time -- external tools need to know
    which version they are seeing

  ~ there's lots of "weird branches" of `tla' running, combining a
    little bit from here and a little bit from there.

That second point underscores for me the need for standards (I'm
working on it, actively but slowly).   But about "features".....

I'm still a little vague on what they are.  I guess the related
question is "What does it *mean* for a `feature' to be present (or
absent)'?" from which maybe we can figure out how to name features and
how to implement `tla features'.
  

    > > An answer implies/includes, to name a few things, how feature names
    > > are decided, who/how feature presense/absense is asserted, what valid
    > > feature names are, etc.

    > *If* (or when?) tla (the app) becomes extensible, a mechanism should
    > exist to exted the features database, so I could say
    > (provide 'signed-archives) or [horrors!] (provide 'max-speed 12).

That is close to a design trap you are falling into there.

You can see some nice (rough) analogy to another system, so you posit
the (underspecified) existence of some feature based on that analogy,
then show how it would be fun to have, then convince everyone to go
off and implement it.  (I'm not accusing *you* of going overboard
.... I'm just pointing out a trap that is easy for anyone to fall
into.)

The problem: nowhere in that process, between you thinking of the
analogy and you convincing everyone to work on something, did you
actually "validate" the analogy.   Possibly the analogy makes no
logical sense and everybody's work will be wasted.

What does "add (provide 'signed-archives) to tla" actually,
rigourously, actually *_!_mean_!_*?

Coming up with the idea is an excellent thing to do.   It's a creative
technique (one that generates innovation, reliably) to cut-and-paste
concepts that way and come up with suggestive analogies.

But the creative technique is a two part process and the second part
is filtering out the crazy, illusory suggestive analogies from the
ones that actually make sense.

So, again:

It's a little early to ask "features: yes or no?" because we don't yet
have any pleasing and precise answer to "features: what does it do?"

-t





reply via email to

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