[LONG] comments on Tunes etc.

[zccap74]

> > Ok, so in a practical sense a meta-language/system then needs to be
> > defined which can be extendable, incorporate security features +
> > originator info,
> 
> Exactly...
> 
> > 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'?

Yeah, oops I'm sorry: By a packet I mean a code or data block - the
reason I was phrasing it like this is that they need to be robust
entities in a similar fashion to IP packets. nb. the arguments of real
time delivery, data organisation etc. apply too.

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

And the way ML/ XML/ SGML handles this as a meta-language is that the
ad-hoc standard has to be defined before the data is read. This approach
means that any translator which understands ML can 'read' through the
ad-hoc definition and also understand it.

I'm not advocating ML or it's offspring (NeSL, XML, SGML etc.) as the
way forward, particularly as it has been done before and the
implementation was too cumbersome (see language review page) for a base
structure to build upon.....

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

Which brings me nicely here. The above is certainly what I was thinking
of, but I thought that the basic idea was to make an implementation as
light as possible so it runs cleanly + fast.
The multiboot standard specifies a light way of loading 'packets' into
an execution space - it's been designed to be platform and language
independent and I think extensible (check).

> 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 agree another 'standard' is the last thing we need, but why not
'piggy-back' from another standard if it suits our needs?
This has the added advantage of having pre-developed code and allows us
quicker development and (some) external support from other coders in
that area.

This is why I was suggesting the multiboot standard as something to
start from, and add any required meta-data representations to it.

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

Mmmmm, this sparks off database object tracking.....which I have no idea
about how this can be integrated with the above thoughts, but should be
taken into consideration somwhere. (perhaps ID based?)

Basically, if we have a good meta-data system, most code can be adapted
to feature it and thus becomes part of the TUNES system as the meta-data
controls the code-object.

That's all for now folks!
Alexis Read