[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Typeability and screen space
At 12:15 PM -0800 3/29/97, Ron Rivest wrote:
>I don't buy your arguments, Carl. I still think that we should only have
>the long forms without abbreviations (although we can try to keep the "long
>forms" from being too long", which is one reason I prefer "ref" to
>"fully-qualified-name".
I have to agree with Ron. If Carl's primary arguement is that short names are
"more easily typeable", rhwn I don't buy it. The reason is that if you are
going to be using an editor you are going to be doing alot of copy and
pasting of base64, other text, etc., thus you can easily copy and paste the
longer names.
Another reason: the editor that I use is extensible -- I can just triple
click to select this paragraph and just click on "digest" and I get
( Object-Hash: ( SHA1: #c3b3799f51bdd256934d386688235f85cb1196da ) )
( Object : "Another reason: the editor that I use is extensible -- I can
just triple click to select this paragraph and just click on "digest" and I
get" )
[BTW, the above digest is real -- if anyone uses BBEdit for the Mac I'd be
glad to share our experimental extensions.]
I can also type a "nickname" and a command-key and the nickname expands to
the full name. For instance, the nickname mymail expands to Christopher
Allen <ChristopherA@consensus.com>.
>-- I think that typeability should NOT be an issue here. We are almost never
> going to type these things. (Even for the documentation, we can take
> output from the code.) Readability is MUCH more important than
> typeability. I may forget whether S stands for Subject, Signature,
> SPKI-version, or what, and don't want to have to look it up.
I also agree with Ron on readability.
>-- While you are right that some programming systems have over-long names,
> we only have a handful of such names here, and we can choose them
> carefully.
I'd be glad to set a requirement that names are not *too* long, but agree
with Ron that names defined by SPKI will be few in number and thus should
be as undertandable, unambigious, and clear as possible.
>-- Screen space is NOT an issue, because it is essentially the same issue
> as for the general compression (we are probably only going to save 15%
> at most for total bytes with the short forms). Furthermore, for screen
> display you probably want it nicely idented, which means that you will
> care more about lines of display rather than number of bytes anyway, and
> the increase in the number of lines displayed is probably going to be
> under 5% for typical stuff...
I agree with this arguement.
>I still vote for a single form for each object name...
I to vote so.
------------------------------------------------------------------------
..Christopher Allen Consensus Development Corporation..
..<ChristopherA@consensus.com> 1563 Solano Avenue #355..
.. Berkeley, CA 94707-2116..
..Home of "SSL Plus: o510/559-1500 f510/559-1505..
.. SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..
Follow-Ups:
References: