[Oberon] Re: filesystem with directories ?

[easlab at absamail.co.za]

Doug Danforth wrote:
> What this whole thread comes down to is information 
> retrieval and pattern matching.

Yes information retrieval, inevitably BY pattern matching.
That's why I've said 'find' utilities are important, and
why Google has become important to 'humanity', and
since time/recentcy(?sp) is a natural attribute of things, so
sorting [stacking] by 'newness' is often more meaningfull 
than alphbetical sorting.

Some interesting schemes have been raised in this thread which 
we [ETH community] will never implement. But I think OP
wants a solution NOW.  Well I too was becoming very
unsatisfied as my file-count increased, until partitions 
were implemented for N-O.

Some writer[s] have trivialised "only for human convenience".
But for P[ersonal] Cs [vs computers for automatically operating
machines] nothing can be more important than 'human 
convenience'.

We count in decimal only 'cos we've got 10 fingers, and having
20 to 30 letters is also only a human limitation. IMO the "7 +-4
rule" is not insignificant: most people can only remember 3 
to ?..7 things.  So a deep heirarchy becomes humanly 
unmanagable.

The idea of using fileIDs like:
John.animal.cat.blue.big
John.animal.dog.red.small
...
seems not so good to me.

1.The important HUMAN attribute based principle of 
'information hiding' is lost.  When I'm working in my 
medical-partition, I don't want to be distracted by my
telecommunications-partition's files.

2. Has "." [dot] got any [non human] extra significance as a 
FileIdChar ?  As previously stated, I no longer use *.Text,
since a false 'chord' on 'JohnText' won't give a potentially
dangerous command: P.M ; as John.Text could.

3. we don't want to see long FileIDs [which are mostly 
redunant] when smaller ones will do ? BTW a killer aspect
of N-O is that you need/should never type-in a fileID
except at its initial creation.
 ------------

No one mentioned that apparently N-O's 'B-tree' scheme is
apparently faster than Win or Linux ?

So yes, the OP is realistically justified in wanting different
file-space-categories, to assist in management eg. searching.
I've found 3 levels of heirarchy OK for my text files:
 partitions >  files > 'chapters'.

My 'chapters' are like this; eg. the begining of my 'TelCom:RFCs' looks
like:
1.  1855 = Netiquette Guidelines
2.  Uniform Resource Locators (URL)
3. POP3 - 1939
4. RFC-Editor Webpage
5. POP3 - 1725
....etc.
18. SMTP Service Extension for Authentication = RFC 2554
19. Using TLS with IMAP, POP3 and ACAP = RFC 2595
20. Requirements for Large-scale Multicast Applications = RFC 1855

Self explanitory:
partitions= TelCom, files=RFCs and because of N-Os magic 
chording-speed, you get [in the TextFrameOfTheFile] down 
to the begining of the 'chapter',
eg. '3. POP3 - 1939'  in a fraction of a second.

Perhaps partitions are not available on WinAos/BB ?
There is a potential problem/danger with partitions: since they are
implemented by a chain of links, if the chain breaks at partition
N all further partitions are potentially lost, unless the 'partition
linking info' has been saved -- which is easily done when the 
partitions are initially created.  But needs to be documented.

It's these trivial/naive details which make for robust usability ?

So if you have a dozen conceptual-categories, and you want
say 3 cycles of backup-roll-over, you'd need 36 partitions.
I must admit that backup is problematic.

Searching a partition is fast.
Using a 'pre-compiled' list of non-redundant files:
   ie. omitt the *.Bak and 
   having a textFrame eqivalent of 
      System.Directory TelCom:* 
    PLUS extra potential info via differently coloured FileIDs
   [N-O's quickColouring of text ads powerful/cheap intellignece
     to data. eg FileIDs with a certain attribute (which may be only
     applicable for some-time <while they're 'current'> can be
     appropriately coloured)], 
which is called 'TelCom:SearchTemplate' , and which looks like:
---------- start of file:
Updated 2004 Dec 31  Find.All ^ Find.MultiPatrn "DECT" "axton" ~

Find.Domain
TelCom:Abreviations
TelCom:AmtSatlFAQ.html
.....
TelCom:hylaFAXsrvr.html
TelCom:uPinstrmtPrjct
~
---------- end of file.
This Text [dir of files] is only updated when new files are added, which 
is seldon, since most additions are 'chapters' to existing files.
Of course with clumsy Windoof eg. where you can't easly search,
cutNpaste, ...etc. such schemes are not practical. 

To find <textString> in the partition, you just select <textString>
and hit 'Find.Domain' & 'Find.All ^'.

For 'the list of files which contain the set of strings [in any order]'
I've modified the existing Find.Mod - with a disgusting unstructured hack
which hopefully someone will clean before it's admitted - because
some times one is desperate to find the file which contained that
strange set of words scattered somewhere in the text.

Suggesting search keys is an art ?  I sometimes go into a trance to
dig out recollections from my sub-concious.
----------

That hard-AI failed, and that tools which interface well with humans 
have yielded powerfull results, suggests that N-Os way of having 
convenient [good human interface] tools is the most fruitfull route.

Columbus and Watson are good examples of tools which can help
move the system forward.

... to be continued as new thread: "Evolving tool sets..."

== Chris Glur.