At 2:48 PM -0800 1/23/03, Brent Dax wrote:
Heh. I try and avoid the absolute statements. This is all engineering, and engineering is applied economics--you juggle features and make compromises to get the thing that meets your needs as best as possible at a cost you can manage. Allowing extensibility is Really Keen, but has its associated cost that has to be balanced against everything else.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.
Having said that, I think we can do this, but I want a better feel for what we need, what we want, and what it'll cost before we make a decision.
Yes and no. Yes in that I want the first few chunks, the ones that are required, to be at fixed offsets. Following that will be a directory, and from there we can index off to wherever we need to.Are you expecting to have chunk type determined by order?
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
