RE: Re: [9fans] acme: some thoughts about design

RE: Re: [9fans] acme: some thoughts about design

[Tiit Lankots]

> If I have a usefull search interface I didnt need any 
> filename or directory structure. A user isn't interessted in 
> filesystems.

A smart user is. When your file count passes 200 000, you won't know
your
left from your right in a flat file space. Hierarchy is your friend.

Re: Re: [9fans] acme: some thoughts about design

[Tristan Seligmann]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

On Sat, May 29, 2004 at 19:51:56 +0300, Tiit Lankots wrote:
> > If I have a usefull search interface I didnt need any 
> > filename or directory structure. A user isn't interessted in 
> > filesystems.
> 
> A smart user is. When your file count passes 200 000, you won't know
> your
> left from your right in a flat file space. Hierarchy is your friend.

A 2-dimensional hierarchy is hopelessly inadequate for storing
information in a "natural" way. People retrieve information along many
different "vectors" all the time, and a hierachical filesystem only
really has 1 or 2. It may be a great low-level implementation, but being
able to say "find the e-mail I wrote to Timothy last week" is a lot more
useful to the user.

-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

[-- Attachment #2.1: Type: text/plain, Size: 333 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/pgp-signature; name="signature.asc"
	Content-Description: Digital signature
	Content-Disposition: inline

[-- Attachment #2.2: signature.asc.suspect --]
[-- Type: application/octet-stream, Size: 196 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAuME6pNuXDQIV94oRAmQJAJ0ZmTsVYpEtwwmaeWFF1BT8Ry6tmgCeMfok
VRFhF0lX8kpkTim4H8O25YE=
=Tn8l
-----END PGP SIGNATURE-----

Re: Re: [9fans] acme: some thoughts about design

[dvd]

> A 2-dimensional hierarchy is hopelessly inadequate for storing
> information in a "natural" way. People retrieve information along many
> different "vectors" all the time, and a hierachical filesystem only
> really has 1 or 2. It may be a great low-level implementation, but being
> able to say "find the e-mail I wrote to Timothy last week" is a lot more
> useful to the user.

http://www.gmail.com/

RE: Re: [9fans] acme: some thoughts about design

[Matthias Teege]

On Sat May 29 16:59:54 GMT 2004, t.lankots@aprote.ee wrote:
> A smart user is. When your file count passes 200 000, you won't know
> your
> left from your right in a flat file space. Hierarchy is your friend.

Take a look at google. There are more then 200000 Dokuments
indexed and the user didnt now anything about the structure
of the "google fs". But If you need "structure" you can store your
"path" inside the document und use the search engine to
rebuild the structure on the fly. Operas M2 is a example for
that.

Matthias

Re: Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> Hierarchy is your friend.

yup

Re: Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> A 2-dimensional hierarchy is hopelessly inadequate for storing
> information in a "natural" way.

nonsense.

> really has 1 or 2

run du -a lately?

> It may be a great low-level implementation, but being
> able to say "find the e-mail I wrote to Timothy last week" is a lot more
> useful to the user.

really?  mbox/Timothy/* or mbox/Timothy/YYYY/MMDD/*

Re: Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> From: "Tristan Seligmann" <mithrandi@mithrandi.za.net>

send ascii text, this not the NSA.

Re: Re: [9fans] acme: some thoughts about design

[Tristan Seligmann]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Sun, May 30, 2004 at 00:48:40 +0200, boyd, rounin wrote:
> > really has 1 or 2
> 
> run du -a lately?

The problem is, if I want to associate a file with, say, "computers" and
"vaccuum cleaners", how do I layout my filesystem? (let's say the file
is a write-up about computer-controlled vaccuum cleaners)

> > It may be a great low-level implementation, but being
> > able to say "find the e-mail I wrote to Timothy last week" is a lot more
> > useful to the user.
> 
> really?  mbox/Timothy/* or mbox/Timothy/YYYY/MMDD/*

Ok, now what about "all work-related e-mail I wrote about cars last
month"?

All of these queries can be "displayed" via a hierarchical file view,
but not simultaneously; you could of course build multiple "views" using
symlinks or unions or similar, but that's what I'd consider
"higher-level".

-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

[-- Attachment #2.1: Type: text/plain, Size: 333 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/pgp-signature; name="signature.asc"
	Content-Description: Digital signature
	Content-Disposition: inline

[-- Attachment #2.2: signature.asc.suspect --]
[-- Type: application/octet-stream, Size: 196 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAuSMzpNuXDQIV94oRAniKAJ9JFHoi3LyNeERKi08yEEV5zum5AgCeO3cR
LQwylAh3aXdh8VPYLIWSfPs=
=rUWi
-----END PGP SIGNATURE-----

Re: Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> The problem is, if I want to associate a file with, say, "computers" and
> "vaccuum cleaners", how do I layout my filesystem?

organisation?  smarts?

reverting to a serach engine is excessive.

oh, i can't find my remote control ... hmm, better find it with a search engine.

Re: Re: [9fans] acme: some thoughts about design

[Tristan Seligmann]

On Sun, May 30, 2004 at 01:59:21 +0200, boyd, rounin wrote:
> > The problem is, if I want to associate a file with, say, "computers" and
> > "vaccuum cleaners", how do I layout my filesystem?
>
> organisation?  smarts?
>
> reverting to a serach engine is excessive.

Maybe not a search engine, but even something like being able to "tag" a
document with various categories etc. and then being able to view files
matching a combination of tags would be more powerful than "just" an
HFS.

--
mithrandi, i Ainil en-Balandor, a faer Ambar

Re: Re: [9fans] acme: some thoughts about design

[Joel Salomon]

Tristan Seligmann said:
> Maybe not a search engine, but even something like being able to "tag" a
> document with various categories etc. and then being able to view files
> matching a combination of tags would be more powerful than "just" an
> HFS.

Hans Reiser, in "Name Spaces As Tools for Integrating the Operating System
Rather Than As Ends in Themselves" http://www.namesys.com/whitepaper.html
has some interesting thought along those lines, where "paths" can be
semi-structured:
 [subject/[illegal strike] to/elves from/santa document-type/RFC822
ultimatum]
unstructured:
 [santa illegal strike ultimatum elves]
or completely structured:
[subject/strike to/elves from/santa document-type/RFC8221]

he says:
> [this last] query is structurally equivalent to a relational query. Many
> authors (e.g. semantic database designers) have written papers with good
> examples of standard column names which might be worth teaching to users.
> So long as they are an option made available to the user rather than a
> requirement demanded of the user, the increased selectivity they provide
> can be helpful.

He's likely to implement under linux first, but this idea really needs its
own OS to realize fully.

<ramble>
Automatic indexing of a file system is another idea that could be useful -
maybe atop venti, along with fossil? some program to index blocks as they
are written to venti and associate the index block with the data block.
Get access permissions from fossil. Get fancy and check file types
(file(1)), and have specialized indexers for different types (though M$
has a couple of patents you'd likely be stepping on here). Probably good
for a master's thesis in computer science.
</ramble>

> mithrandi, i Ainil en-Balandor, a faer Ambar
Translation?

--Joel

Re: Re: [9fans] acme: some thoughts about design

[Joel Salomon]

dvd@davidashen.net said:
> http://www.gmail.com/

Which nobody can test without an explicit invitation (hint, hint), but
columnists who have it say they like it (forget who at the moment).

--Joel

Re: [9fans] acme: some thoughts about design

[Bruce Ellis]

if you can't organize your data store then you probably
can't find a clean towel either.  the "drop it all on
the floor and expect the floor to be your friend" is
delusional.  and i still can't find the remote control.
just use the right tool for the job.  i didn't use
"diff" to compare the '96 and the '98.

http://www.pikeswines.com.au (nice fish)

and there is no need to clean a vacuum.

brucee

boyd, rounin wrote:

>>The problem is, if I want to associate a file with, say, "computers" and
>>"vaccuum cleaners", how do I layout my filesystem?
>
> organisation?  smarts?
>
> reverting to a serach engine is excessive.
>
> oh, i can't find my remote control ... hmm, better find it with a search engine.

Re: Re: [9fans] acme: some thoughts about design

[a]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1258 bytes --]

i don't think anybody's seriously questioning the general
utility of search capabilities. but the directed graph we
currently have is very useful for all sorts of things. it
is, for example, a very "natural" (but see later) layout
for source trees and related documentation.

i really like (and have for a while) the "tagging" idea
(although i don't think i ever thought to call it that).
it's still active on the part of the user (which i like,
but folks interested in having the idea of saving go away
likely won't), and organizes things based on ideas the
user has about the document, not arbitrary search.

there is no "natural" way to store files on a computer.
our brains weren't designed for it. any scheme we come up
with to store them runs smack up against that. we can try
to find useful ways that we can adapt easily to, but that
really is the best we're getting. and be very careful
about choosing what seem to be "natural" ways to store or
organize stuff - read "The Anti-Mac Interface" or any of
the many papers on how the desktop metaphor seriously
limits the utility of an interface.

i can't find the attribution just now, but "the only
intuitive user interface is the nipple. after that, it's
all learned."
ÎÐÉ

Re: [9fans] acme: some thoughts about design

[Bruce Ellis]

directed, of course - that's what walk does.
but not necessarily acyclic, unless you have
a really uninteresting namespace.  that's why
cp -r is fraught with peril.

brucee

a@9srv.net wrote:
> i don't think anybody's seriously questioning the general
> utility of search capabilities. but the directed graph we
> currently have is very useful for all sorts of things. it
> is, for example, a very "natural" (but see later) layout
> for source trees and related documentation.

[9fans] acme: some thoughts about design

[cej]

>> Am I wrong?
>
>yes
>

why?

++pac.

Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> Am I wrong?

yes

[9fans] acme: some thoughts about design

[cej]

> sounds like you want sam, but with acme style execute semantics.
No, I would love commandline-Sam using acme as interface. Am I wrong?

++pac.

Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> What I'm thinking about is to simple type somthing like that:
> 
> "Dear customer, please pay < hoc -e '47.11 * 8.15' Euros, as
> fast as you can"

yeah, i had thought of that.  a1-2 chord would be nice.

Re: [9fans] acme: some thoughts about design

[Matthias Teege]

> i can't actually believe i'm about to say this, but:
> 
>     button-1 to select and hold down and button-2 chord to execute it.

;-)

What I'm thinking about is to simple type somthing like that:

"Dear customer, please pay < hoc -e '47.11 * 8.15' Euros, as
fast as you can"

and then mark '< hoc -e '47.11 * 8.15' and execute it in that
way, that the result replaces the selection. This is somthing
I can explain to a clerk.

send a command to the command window without
snarf/paste is a nice idea.

Matthias

Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> Yes!, mark and execute in any sam window maybe with an
> execute key on keyboard.

i can't actually believe i'm about to say this, but:

    button-1 to select and hold down and button-2 chord to execute it.

i just thought of a problem,  but:

    button 2: does a !text send in the command window
    button 3: text send in command window

you want to be able to execute external as well as internal sam commands.

i was thinking of Put and w and am not sure what stdin/stdout should be for external commands.

this may require some thought.

Re: [9fans] acme: some thoughts about design

[Matthias Teege]

On Thu Jun  3 09:40:03 GMT 2004, boyd@insultant.net wrote:
> sounds like you want sam, but with acme style execute semantics.

Yes!, mark and execute in any sam window maybe with an
execute key on keyboard.
Matthias

Re: [9fans] acme: some thoughts about design

[boyd, rounin]

sounds like you want sam, but with acme style execute semantics.

[9fans] acme: some thoughts about design

[cej]

Thanks for reaction! Here is some explanations to what i meant...

/As I mentioned earlier, wouldn't a frame with [sorted] listing of
//window tags be a cleaner solution for navigation?

> i don't think so, no. how would it work? say i have some window
> containing this list. how's it sorted? lists are one-dimensional; my
> acme window arangement is not. while there's a trivial way to do
> the transformation (go down col 1, then col 2...), that becomes
> quite awkward, mentally.

why? the list will always take you to the correct place, won't it? otherwise, OK, one  could have such window for each column separately...

> but the biggest problem is that i want to look at a window and
> know which file i'm editing. 

cursor position | highlighting in "listing/tag window" not sufficient?
 
> i have a lot of acme windows most of

so do i ;-)

> the time, and counting down a list - even given some kind of
> markers denoting col boundaries - seems like it would take
> forever.

> and how would commands work? how do you tell Put which
> window to Put if they're all in a list?

use last "ordinary window" ... i think

> actually, this all sounds so bad to me i've concluded i don't
> really understand what you're suggesting.       care to sort me out?


best regards,
++pac.

    

Re: [9fans] acme: some thoughts about design

[a]

bugger. backspace didn't work out so well. huh.

Re: [9fans] acme: some thoughts about design

[a]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 919 bytes --]

//As I mentioned earlier, wouldn't a frame with [sorted] listing of
//window tags be a cleaner solution for navigation?

i don't think so, no. how would it work? say i have some window
containing this list. how's it sorted? lists are one-dimensional; my
acme window arangement is not. while there's a trivial way to do
the transformation (go down col 1, then col 2...), that becomes
quite awkward, mentally.

but the biggest problem is that i want to look at a window and
know which file i'm editing. i have a lot of acme windows most of
the time, and counting down a list - even given some kind of
markers denoting col boundaries - seems like it would take
forever.

and how would commands work? how do you tell Put which
window to Put if they're all in a list?

actually, this all sounds so bad to me i've concluded i don't
really understand what you're suggesting. â˜â˜care to sort me out?
 ï

[9fans] acme: some thoughts about design

[cej]

> > The thing I don't like [very much] is taglines [as a place for commands]:

> if you don't want to use the taglines for commands, don't.

> the taglines are necessary -- how else would you know
> which file was which?  putting extra stuff in them that can
> be ignored seems like an efficient use of space, not a waste.

As I mentioned earlier, wouldn't a frame with [sorted] listing of window
tags be a cleaner solution for navigation?

++pac.

Re: [9fans] acme: some thoughts about design

[Matthias Teege]

> The thing I don't like [very much] is taglines [as a place for commands]:
> they waste screen space, show redundant info (same commands all the time)
> couldn't we have a *single* command 'window'[==acme's frame, not rio window]

A "command window" introduce a mode. It's better If you can
input a command in any place and execute it with a "execute key" like
acme does.

Matthias

[9fans] acme: some thoughts about design

[cej]

Hi, there!

First... I love Acme's design: chording, no-menus, etc... Nothing pops up, or falls at me, etc,etc...

The thing I don't like [very much] is taglines [as a place for commands]:
they waste screen space, show redundant info (same commands all the time)
couldn't we have a *single* command 'window'[==acme's frame, not rio window]
which would behave much like tagline: show current window's tag plus list of predefined/pasted commands
this would save space on screen, and [IMHO] would bemore elegant solution.
Another frame with [sorted] listing of window tags could ease navigation...

would love also to have acme as an optional universal glue for programs,
eg., Edit functions could move outside to [something like a commandline]Sam (enhanced sed) that would 
then use Acme's frame to display files...

Just a prick in a wasp's nest, I feel, but I would love 
to hear from you, even if [especially if] I missed the point! Don't shoot me.

No need to say that implementation is far, far beyond my skills :-(((


Sincerely yours,
++pac.