[sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags

[Albert Cahalan]

On Sat, Sep 20, 2008 at 10:01 AM, C. Scott Ananian <cscott at laptop.org> wrote:
> On Sat, Sep 20, 2008 at 1:41 AM, Albert Cahalan <acahalan at gmail.com> wrote:

>> The case of b/a being distinct from a/b is necessary. You may call
>> it a necessary evil, but in any case is is necessary.
>
> Surprisingly, it's not:
> http://wiki.laptop.org/go/Experiments_with_unordered_paths
>
> I still think it's worth supporting as an edge case, but from my
> actual experiments, it seems that path ordering is almost never
> actually necessary (!).

Suppose I hand you a 16 GB USB stick or a USB DVD drive.
Suppose it has a million files in 54321 directories, with a
typical path depth of 5 or 6 and a max path depth of 11.
How are you expecting to handle that? (CPU, RAM, IO, etc.)

Suppose the journal grows the ability to deal with CIFS
or NFSv4, as it ultimately must. You encounter a server
with home directories for all students in the school district.
Your fellow students do likewise. You're using wireless.

>> For the journal to be truly usable, it needs to support pretty much
>> all that we ask of a filesystem. You'll know you're doing OK when
>> you can build joyride out of the journal. (git works, gcc works, etc.)
>
> This is a good test case.  I'll confirm it, but I believe that this
> should actually work with unordered paths.  The trickiness comes wrt
> to security in a multiuser system; Michael has been thinking hard
> about that.  (I prefer just to punt it for the moment.)

I'll guess you'll use FUSE? Don't forget readdir().
That could be /bin/ls or $(wildcard *.h) or whatever.

>> Give priority to tags (and anti-tags) which split the set of
>> files most evenly. This greatly reduces search time; it is
>> equivalent to balancing a binary tree.
>
> It turns out that only about 3 tags are needed to find any directory
> among the 900,000 files in my home directory (I'm working on getting
> better statistics, sorry).  So the opposite criterion might be more
> important: give priority to tags which 'most narrow' the search --
> that is, they match the *fewest* things!

No, because displaying tags is not free. They take up screen
space. That imposes a hard limit on the number when you run
out of space, and a squishy limit from mental burden.

If you show enough tags so that "only about 3" will do the job,
you'll be showing a truly huge number of tags. I think it's far
more than dozens, possibly even thousands.

> Once you've entered two
> search terms, the exact thing you are looking for ought to be in that
> list; you don't want to be distracted by terms held in common by lots
> of files which don't appreciably narrow your search.

If you could see the narrow search term right in front of you,
actually being able to find it, that would work nicely. There
are just too many narrow search terms though. You'd need
a way to search your search... uh oh!

It could be reasonable to reserve some (half?) of the precious
screen space for recent/popular search terms though.