Re: [colorforth] Re-connecting

[Terry Loveall <loveall@xxxxxxxxx>]

On Tue, 22 Feb 2005 22:12:28 -0500 (EST)
Mark Slicker <maslicke@xxxxxxxxxxx> wrote:

> On Wed, 9 Feb 2005, Terry Loveall wrote:
> 
> > 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.

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?

> 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.
> 
> My critique of hierarchical file systems is that they put too much burden 
> on the user, to give each file a name and place within the hierarchy. Also 
> they are not very general or flexible. I think the system could be much 
> more active in recording information about data objects, and the system 
> could make this information availible in a general way to applications.

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.

Different data views could be generated by the ordering of a seperate 'order'
link for each data object that gets set by a 'words' type of program that
walks the tree structure and makes links depending on the individual word
definition's attribute. A viewer would just walk the 'order' links displaying
the definition name and whatever other fields are specified.

If links are relative, then contiguous blocks of definitions can be
saved/restored as standard block format in a position independent manner. The
mechanisms are available, just not necessarily in place in colorForth (no
nested vocabulary). And then there is the concern for seperate name headers
(colorForth as is) or inline name headers. Each has its unique advantages and
weaknesses.

All of this came to me as a 'GDuh!' realization after I posted the original
'Re-connecting'. For one off special projects it can be coded on the fly.

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?).

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.

But all of the above could be applied to conventional OS design. See some of
the recent write-ups on beOS. With colorForth, the opportunity is at hand to
try it again.

Regards,
Terry Loveall

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