[LONG] comments on Tunes etc.

[David Jeske]

On Wed, Oct 07, 1998 at 12:35:01PM +0000, zccap74 wrote:
> > 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.

Do you mean a "logical code or data block" or a "physical code or data
block". By logical I mean "descriptive form, what's fed to the OS,
hopefully not binary instructions", and by physical I mean "a physical
block which is ready to be executed on the target processor.

I'm assuming logical.

> > 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 don't see the direct correlation. I'm not just talking about
metadata. I'm talking about orginizations which occur in
code-constructs. Most languages have a system for expressing items
'within the type system'. However, in most languages, you can also
fall back, and just make your 'operation' an argument, and thus the
typed item is meaningless. 

To make a psudo-realistic example from SGML, if I defined a tag "FOO",
which has an argument "NAME" which is a string, then the following
would be legal (in HTML-ease):

<FOO NAME="one"></FOO>
<FOO NAME="two"></FOO>

However, what happens when people create an add-hoc standard for that
name, after the fact? So that certain values of that string have
special meaning. Even if we define the special values as part of the
standard, because the original definition of the item was 'string', we
can never get stringent type checking on the value, because even if it
dosn't match any of our special values, it is still a valid string.

Perhaps this isn't incredibly important, and the greater importance is
being able to know, when we have a document, which add-hoc standards
that document is using so that we can 'do the right thing'.

For example, it would be really nice if we could 'fake' the concept of
dev entries to old UNIX software without having to rewrite all that
software, and without having to structure our OS the same way as
UNIX. Not so much because we care about old UNIX software, but because
software will be written in any system which makes use of similar
add-hoc standards.

> > 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 have to disagree completely here. When trying to bring up an
environment which can do platform independent codeblock -> platform
dependent codeblock translation, we really don't want to have to write
all the device drivers, etc which would be necessary to run in this
'clean' (i.e. bare) environment.

Are you sure you don't mean 'OpenFirmware' and not multiboot?
Multiboot (http://www.uruk.org/grub/boot-proposal.html) is a boot
loader standard which has nothing platform independent about
it. OpenBoot/OpenFirmware is a FORTH based standard for creating
'bootstrap drivers' which are platform independent. It was adopted
from Sparc's boot standard, and is now used most notably by Apple
computer for bootup on the PowerMac.

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

I don't have any problem with recognizing standards, although my ideas
are centered around being able to recognize all standards, not just
one.

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

You'll have to comment on whether you really mean OpenFirmware...

> > 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?)

I'm certainly thinking along the lines of a database orginization
(like a multi-dimensional database). I really want to store all data
in a big flat soup, and just define relationships between those items,
or relationships between those items and 'concepts' in the world. What
I'm thinking of is a cross between BeOS's 'atbirary attributes' and a
Capabability based systems' nodes/pages concept
(http://www.cis.upenn.edu/~eros/).

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