Mail Archives: opendos/1997/05/04/23:28:14
> From dz AT bo DOT dada DOT it Sat May 3 20:05:39 1997
> Alaric B. Williams wrote:
>
> > Another way is to have standard COMMAND.COM commands in text
> > fields. This isn't quite as powerful, but will be quicker;
> Well, why only COMMAND.COM commands ?
> Couldn't be better a filename.EXE in a directory writeable only by a
> 'root' ? So no virii could enter, a new handler could be added and
> everybody is happy :-)
> To make a dir r/o it could be 'mounted' as another R/O FS...
The files should be "portable", so a script language (Java is a good
thought too) would be nice. But I wouldn't want to have too many
executables floating around with data (too much disk space used, slow
to load, big security headaches, portability always a problem).
And I like the Object-oriented approach (especially OS/2's: it should
be possible to use all the information an OS/2 system accumulates about
a file). But most of the time all you need is an indication of what is
needed to "use" the file.
There is a neat system I like for sending LaTeX documents to thers that
checks for the non-standard style files etc that the document uses, and
sends those as well. Inside the organisation all you need is the one
file; outside these others to ensure you have all you need for the
document.
So how about having a system where a file has attributes including
"what class of viewer" is needed for the file, plus (if it needs it,
and hopefully most won't) what is the minimal version/feature set
required. Feature set might be loadable modules in the viewer/editor,
or might be things like a modem, or .h files, .tpu units, .sty files,
etc. If you send the file to somebody outside the computer system it
will include those files needed, instead of simply a message to the
system that they are needed.
We shouldn't see a 10Mb executable sent along with a one-page document,
nor a situation like the IBM "introduction to java" web pages requiring
a netscape module that isn't available under most operating systems. We
should rarely see a need for a particular module, just given features.
But a Java script for a desktop package would be okay. If you get a file
for which no local addon is available, you'd get a message once from the
system about installing that module in your filesystem's library.
The file would then be stored with only a message saying what it needs,
referring to the module by name, not location. Possibly the module would
store a link back to the file9s) that need it, especially if only one file
uses it, so it can be deleted when no files remain that need it, or when
another module comes that has all the required attributes but it newer?
Mark.
- Raw text -