Prev: Question about C64 to PC Interface Cable Needed.
Next: C= Wine at CommVEx v4
From: christianlott1 on 22 Apr 2008 20:44
A simple search algorithm and a very specific type system within a
transparent DOS.
---------------------------------------------------
keywords: logical vs physical storage, scalable, compact, type system
---------------------------------------------------

I don't know of any better way to store files than by type.

Yet type and type systems can be pretty nebulous.

For a definition we'll say Type designates which _type_ of program can
read this file.

Suddenly we're in a very small world -

1) good -
a) we can glance at the file and usually know what's up AND
b) we can search by this -file type-
2) bad -
a) count on a zillion file types and even more programs claiming to
read the file
b) many (compound) files have multiple types of data in them.

Maybe a better approach is to have a common data definition file.
Therefore the storage/retrieval/update mechanism can be as finely
tuned as needed.

As an example - a PRG file.

First two bytes tell it where to load, next comes program data.
Program data is pretty vauge. It could be a basic program ($0801 if
loading at the default address) or assembler. If it's an assembler
file we probably have some data mixed in with it like text strings,
dos commands, sprite or character data, etc.

Obviuosly this small world of SEQ and PRG file types get's pretty
obscure. It's fine if you're working with a handful of files but the
problems get excessively worse if you throw MBs and GBs of these
things together. It's not just searching that takes a long time
though. A vauge type system leads to exponential patches, searches and
an increase of even more file types.

A DOS that understands it's data can classify and store it
intelligently. The more type specific you get, the greater the
resolution and the faster and more robust the search, within the file
or outside it (across files). It can also compact it more easily.

With such a system storage becomes less of a 'where' than a 'how'. You
can say you want it under X/Y/Z directory but that suits only one
simplistic way of accessing this data.

Armed with a Data Definition File, a set of bytes with a common
notation answering to a greater or lesser extent the 'what and where'
of data within the file, you've given the DOS more leverage to help
you find, store (compact) and retrieve.

From: Joe Forster/STA on 22 Apr 2008 21:26
See GEOS for extended file types and an extra info sector - including
icon, comments etc. - of common format. Also see metainfo in the Amiga
and MacOS file systems. (Don't know much about these, having only seen
them extracted into binary metafiles in ZIP archives and on FAT file
systems.)
From: Jim Brain on 23 Apr 2008 00:18
christianlott1 wrote:
> A simple search algorithm and a very specific type system within a
> transparent DOS.

As Joe notes, GEOS did this, as did MacOS and Amiga, and OS/2 did. NTFS
offers the ability as well with it's alternate data streams, but no one
uses it for that, to my knowledge.

I want people to keep posting these ideas. But, understand that those
of us who are implementing cannot possible implement these ideas at the
rate they arrive in the forums/USENET. I just want to set expectations.

I don't know about this idea in general, but here's some thoughts.

o Many times, a file can be ascertained by the first few bytes of the file.
o sd2iec/uIEC already opens some files when obtaining a directory (P00
et al. files have to be actually opened to grab the internal PETSCII
name from the file).
o The other day, Klomp or Pheque suggested an idea of a load"$",8
actually loading a small directory viewer application, and then that
application would load the directory and display it. Sort of an
autoloaded dir browser, built into the drive.
o The idea could be be extended.

If there were signatures on hand for various "types" of files, something
like (I doubt this syntax would work, but you'll get the idea) load
"v[iew]:doodle.seq",8 would look up doodle.seq, check it against some
signatures, and determine that it's a doodle file, note that the user
asked to "view" the file, and the drive would serve up a doodle image
viewer of the user's choice and then the viewer would load the actual
doodle with open1,8,2,"doodle.seq".

Other actions could be "e[dit]","p[rint]", etc.

That is not terribly difficult to implement, assuming someone does the
legwork on the signatures and the signature could be found in the first
256 bytes or so.

Jim


From: BruceMcF on 23 Apr 2008 10:11
On Apr 23, 12:18 am, Jim Brain <br...(a)jbrain.com> wrote:
> o Many times, a file can be ascertained by the first few bytes of the file.

Yes, this is how the Unix utility to find a file type works.

> o The other day, Klomp or Pheque suggested an idea of a load"$",8
> actually loading a small directory viewer application, and then that
> application would load the directory and display it. Sort of an
> autoloaded dir browser, built into the drive.

> o The idea could be be extended.

> If there were signatures on hand for various "types" of files, something
> like (I doubt this syntax would work, but you'll get the idea) load
> "v[iew]:doodle.seq",8 would look up doodle.seq, check it against some
> signatures, and determine that it's a doodle file, note that the user
> asked to "view" the file, and the drive would serve up a doodle image
> viewer of the user's choice and then the viewer would load the actual
> doodle with open1,8,2,"doodle.seq".

> Other actions could be "e[dit]","p[rint]", etc.

> That is not terribly difficult to implement, assuming someone does the
> legwork on the signatures and the signature could be found in the first
> 256 bytes or so.

Even easier to implement it as a directory information file, where a
file contains a named file type for each file that has had a type
applied. Then its a free-standing utility to guess the file type from
the head of the file that can be used to create an initial directory
information file, with an option to specify the type for files that
the utility cannot guess ... or to change/extend the type for files
with deceptive signatures.

From: Jim Brain on 23 Apr 2008 11:20
BruceMcF wrote:

> Even easier to implement it as a directory information file, where a
> file contains a named file type for each file that has had a type
> applied. Then its a free-standing utility to guess the file type from
> the head of the file that can be used to create an initial directory
> information file, with an option to specify the type for files that
> the utility cannot guess ... or to change/extend the type for files
> with deceptive signatures.

Easier to implement, but easier to break, if you're in the CF/SD space,
as that file would not be updated with new files stored on the card.

I'd rather implement the "utility" in the DOS space, as it'd be always
available to fall back. Then, a later "file", as you note, could be
used to shortcircuit the utility.

Jim
 |  Next  |  Last
Pages: 1 2 3
Prev: Question about C64 to PC Interface Cable Needed.
Next: C= Wine at CommVEx v4