Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# >Dan Sugalski:
# ># Since it looks like it's time to extend the packfile
# format and the #
# >in-memory bytecode layout, this would be the time to start
# discussing #
# >metadata. What sorts of metadata do people think are useful
# to have #
# >in either the packfile (on disk) or in the bytecode (in memory).
# >
# >I do think that, whatever "native" (i.e. understood by
# Parrot) metadata
# >we support, we *must* allow for extensibility, both for
# future native
# >metadata and for third-party tools.
#
# "Must" is an awfully strong word, there. We don't really "must" do
# anything, though I do realize the feature is useful, hence my
# question.

A strong word for a strong opinion.  :^)  Besides, I did qualify it with
an "I do think", which is another way to say IMO.

# >  Moreover, this must not be
# >implemented with a special type of metadata block, or by using
# >sequentially-increasing numbers.  (The first means that any
# metadata we
# >decide to add in the future will be slower than the metadata we add
# >now; the second has problems with several third-party tools
# picking the
# >same
# >number.)
#
# I'm afraid extensible metadata is going to live in its own chunk
# unless someone can come up with a way to embed it without penalty.
# (And I'm generally considering using separate chunks for the metadata
# the engine does understand)

Are you expecting to have chunk type determined by order?  If so, what
will you do if a future restructuring means you either don't need chunk
type X or you need a new, highly incompatible version?  Will you leave
in an "empty" ghost chunk?

I would suggest (roughly) the following format for a chunk:

           TYPE: One 32-bit number
        VERSION: One 32-bit number; suggested usage is as four eight-bit
components
           SIZE: One 32-bit number of bytes (or maybe 64-bit)
           DATA: arbitrary length

For C-heads, think of it like this:

        struct Chunk {
                opcode_t type;
                opcode_t version;
                opcode_t size;
                void data[];
        };

Type IDs less than 256 would be reserved to Parrot (so we have plenty of
room for future expansion); all third-party tools would use some sort of
cryptographic checksum of the tool's name and the data structure's name,
making sure (of course) that their type ID was greater than 255.

If there's a directory of some sort, it should record the type ID and
the offset to the beginning of the chunk.  This should allow for a
fairly quick lookup by type.  If you think that there might be a demand
for multiple instances of the same type of metadata, you may want to add
a chunk ID of some sort.

--Brent Dax <brent...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

"If you're God, you know exactly what it would take to convince me. Do
that."
    --Marc Fleury on alt.atheism