[LONG] comments on Tunes and the list archives

David Jeske jeske@home.chat.net
Wed, 7 Oct 1998 00:57:59 -0700

On Tue, Oct 06, 1998 at 03:14:42PM +0000, zccap74 wrote:
> 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.

I lost you now that you started talking about 'packets'. Can you
define a 'packet'?

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

Right, but I want to target something different than what ML does. I
don't know exactly how it should work, but I know that today people
are constantly creating add-hoc standards which can't be safetly

For example, in UNIX, or Windows, we can build add-hoc conventions
into the pathname space, and it might be that forever forward,
everytime we code fopen("/dev/ttyS0","rb+");, we actually mean
something special, because we've created an add-hoc standard. 

I am searching for a way to be able to later go in and specify type
constraints for these add-hoc orginizations, because I recognize that
they will ALWAYS exist.


You lost me with much of the rest... perhaps it'll be more clear when
you explain 'packets'.

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

How is the meta-language going to be based on the multiboot standard?
What I'm thinking of when you say 'meta-language' could be implemented
as a process in a UNIX or windows system, it could run under DOS, it
could be a kernel by itself, but none of those is critical to what
it's doing.

> Also, W3C's site is worth looking at about meta-data issues.

I've seen alot of progress in the 'metadata' realm in general, mostly
in standardization. However, today there exist several similar but
different metadata standards. I don't want to make another standard,
or conform to any of them.

I guess what I'm thinking is closer to what we do in our heads. I'd
like to have the system internally keep track of both 'unique items'
it recognizes from the outside world, and 'relationships' between
those items. It might be that on my system, when I came across the
HTTP/1.1 metadata field "AUTHOR", it was assigned the unique ID "4" on
my system, but on yours it was "10". The important part is that the
system actually has an internal representation for all types it comes
in contact with, and they are not 'hidden' three levels deep in some
software package. That way, when someone says 'Hey, the Microsoft Word
metadata AUTHOR field is exactly like the HTTP/1.1 AUTHOR field' the
system can do something useful with that information.

David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net