| |
|
|
Technical Specs of SHOE
Shoe was designed with the following goals and constraints
in mind:
- as independent as possible from any particular data structures, algorithms, or even user interface. So future version of Data Desk could change any of these, and still have no trouble supporting Shoe.
- easy to write by anyone, should have low threshold of knowledge
- only intended for exchanging data, doesn't have to be in a form immediately usable. ok to require reading the entire file to use any of it. i.e. no central directory needed, which avoids a lot of complexity.
- extendable, so can have new kinds of objects and properties, and allow programs that don't know about them to skip over them.
- no limit on file size (not just 16 bits, or 32 bits, or even 64 bits)
- some ability to salvage file if damaged
- and of course efficiency in space and time
- but willing to spend overhead time to have platform independent format. (for example: no big endian/little endian option)
- can store data at least as compactly as ascii. (DD6 datafiles are a fair bit larger, even when archived ).
- can import without ever crashing or corrupting datafile no matter how damaged the imported file is.
- can read and write in a single pass, no back tracking. helps keep things simple and fast.
- can determine end of file from contents of file
What follows is the design that evolved to meet these goals.
|
|
The
Shoe specification consists of three levels:
level 0 - This
level defines the storage and/or transmission of the stream of bytes upon
which Shoe is based. i.e. file types, clipboard types.
level 1 - This
level defines the overall structure of a Shoe file, independent of its
meaning. i.e. how objects are composed of properties.
level 2 - This
level defines the interpretation of the Shoe file. i.e. object types,
property types, data types.
|
