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