home .. forth .. colorforth mail list archive ..

RE: [colorforth] Re-connecting

> > > I like graphical file managers that sort and select on  different
criteria.
> > > Enables me to paint a new perspective on old data.
> > >
> > > Remembering that a 'file' is an ordered set of data, puts  data
objects
> > > into the filable category. Maybe an OS file structure is  not needed
but
> > > some form of 'filing' is. Unless you like sorting thru a  heap on your
> > > desktop :-)
> > >
> > 
> > Its funny, that is a literal description of my physical  desktop. Heaps
of 
> > papers, no particular organization.
> > I wonder if the  inventer of file 
> > system metaphor was a type of neat and orderly person, keen on 
> > labeling things and puting them in containers. Perhaps he  was user of 
> > physical filling system.
> 

I believe that messy people are messy because they can rely on a good memory
to find whatever they are looking for in their mess, whereas others have to
have a sort method because they have a 'shorter' memory.
This theory comes from my personnal experience. My (physical) desktop is
most of the time in mess but I can find thing easily because I remember
where everything is. As for computers I could give you nearly all block
number of each app in my Forth ( I have about a dozen of utilities ). I've
organized them into a menu, but mainly to avoid typing and ease the use for
others. Maybe it's the same story for filesystem, too.

> Or it may be that the number of 'pages' got to be too large. Could you
> maintain that desktop if each stack held many thousands of 
> pages and you
> needed access to it in different ways several times a day?
> 

No, for sure; but neither I need to use thousands different "objects" (
files or apps ) in a day. I guess that I use a only a dozen on a regular
basis. As I said it is no problem to me to remember a dozen of numbers; for
others, I one could label them with eaiser-to-remember names, yes.
Now it is true that aside from this core dozen of "object" I may need to
acces from time to time some "object" taken in a set of one hundreds, and
there I reckon I really need a mechanism to ease their retrieving.

> > There are opportunities for the computer system to do the filling. 
> > Some existing examples are email, where the emails are presented as they

> > are recieved in a temporal order. Some email clients allow other 
> > presentations like by sender, for example. This is similer to the
example 
> > you give above, with sorting files within a folder by different
criteria. 
> > Perhaps these principles can be generalized and applied  equally to all 
> > data objects, then a file system resembles more a database.

Indeed. If you just want exploit mass storage device you need a blocksystem
or a filesystem.
If you want it to store metadata ( i.e. data on data such as creation date,
owner ( if you are running a multiuser system! )) the you're going to do
database stuff so  to have a DBMS seems to be wize.

> Forth, with a nested vocabulary structure, can provide the basis for
> 'attribute typed' data storage. The basic managed 'physical' 
> tree structure is
> provided by the vocabulary nesting.
> 

It looks like mixing concepts: data storage on disk, vocabularies in memory.
Vocabularies are for words. 

The word "generalized" has been used above; I think this word is written on
one of the gates of programmers' hell.
If an application generates or act on "data objects" ( images, sound,
traffic data, whatever ), then you use this application to manipulate these
objects. I think it makes sense to say that this application ( or one module
of ) should support the managment of these data objects. In Winux you launch
your file manager, go into some subdir, click on a file and the filemanager
reads its config files to guess what app to launch on the file. I suggest to
launch the app first, and then the app presents you the files it has in its
repository. No other program can present best than this app metadata on
these objects, or sort them according appropriate criteria, at a minimal
cost. I'll go further and say that if one wants to rename, delete or copy a
file or data object, then this also should be supported by this same app
only because they are chances that it can do these operations in a smarter
way than a generic filemanager would do ( for instance, if your data object
is made of other data objects, the app could ask if you want a recursive
delete ).
 

[...]
> 
> But for communication oriented apps, e.g. web browser or 
> email client, it
> would probably be worth the effort to provide a rigorously defined
> 'meta-object' format that essentially allows simple 
> replication of creation
> time/date, modified time/date, size determination, owner 
> (hey! what _about_
> security?).
> 

I wondered if you were thinking about XML or something like that because
from a conceptual point of veiw you're talking about some 'format' (
langage? ) to tell things about virtually anything - but the next reference
suggests it was just a wrong guess. Was it?

> The 'meta-object' format could be self-defining, from the simplest
> of returning 'here' to complex self-modifying data 
> structures. See Chucks
> description of OKAD for possible implementationa of this.
> 

 Amicalement,
  Frédéric

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com