[LONG] comments on Tunes and the list archives

zccap74 zccap74@ucl.ac.uk
Tue, 06 Oct 1998 15:14:42 +0000


Some return comments....

>	Instead of focusing on solving the translation problem up front, my
>	interest has instead been focused on creating what I think of as a
>	rigid 'super-typed' system for describing blocks to the system. The
>	translation system itself (as I envision it) dosn't actually know
>	the right way to translate things, but instead merely provides the
>	lowest common denomenator framework for storage of blocks (data and 
>	code) so that externally written translators can do useful 
>	translations.

>     In a nutshell, it's really a simple source to source translation
>     system where the system actually understands what 'form' each level is
>     in, and has enough information to automatically run a program to get
>     to the next level. Just like a simple 'unit conversion system', it
>     merely knows it has 'miles' on the left side, and it wants 'meters'
>     on the right, so it has to apply "miles to feet", "feet to inches",
>     "inches to centimeters" and "centimeters to meters".

> C. Removal of 'add-hoc' orginization/Metadata
>     However, the idea is to allow entities (code or data blocks) to be
>     only identified as 'unique' in an absolute sense. Then layer whatever
>     meanings on top of them that accumulate over time. In my opinion, the
>     important characteristic is that every chunk of data is self-identifying.

Ok, so in a practical sense a meta-language/system then needs to be
defined which can be extendable, incorporate security features +
originator info, and list packet data such as: persistence/execution
requirements, packet size/number, packet I/O.

The packet I/O refers to what calls the packet can process.
The extendability allows the metadata 'layers' to be added in a similar
manner to ML - ie. strongly typed.
The packet number (or ID) is there to allow parallelism and real-time
operation to occur. It would also allow easier garbage collection.
Querying a particular packet would just generate a new packet with the
appropriate originator info, (one previous level only) and the new data
in it.
Security data would be contained with the packet and left for the
translator to make use of it, as with the decision to
compile/execute/store.

Note the arguments of meta-data length vs data length are applicable.

The meta-language I feel needs to be based upon the Multiboot standard -
essentially the bootloader needs the metadata info above to do it's job,
so it makes sense to incorporate tried and tested STANDARD methods as
much as possible.
Also, W3C's site is worth looking at about meta-data issues.

Ok I'm runnig out of time/....
Next installment soon.
Alexis Read