Hi,
since we are now down to 13 bytes housekeeping data per block in
XBlockFile, I will continue working on XStackFile when I next have some
time to program. Since my technique of writing down my thoughts and then
waiting for input from others like Anthony paid off the last time, I'll try
this again. It also helps me think it through correctly before implementing
it. I encourage all others to do the same. It also helps our big group of
non-programmers, as they can see something is happening.
XStackFile is an interface that provides some central functions to access
different parts of a stack, which are stored in collections of blocks in an
XBlockFile. There is a function to get at stacks, backgrounds, cards and
parts, and at properties of any of these. These handlers take a "create"
parameter which you set to TRUE to have it create the blocks in case they
don't exist already.
This is especially useful for complex objects like backgrounds, cards or
parts, because they will only contain those blocks that are actually used.
E.g. if a button never had anything assigned to its contents, it will not
have a block for contents, thus saving 13 bytes. Same goes for scripts etc.
If they're empty, they won't have that block. So, essentially, an object
with lots of properties set and lots of data and scripts in it will be
larger than it would be in HyperCard, but the average object will be
smaller, hopefully.
Properties are stored two ways: The ones that can be stored at a fixed
size (e.g. rect, style, hilite and other boolean properties) are all kept
in one block, at different positions. Properties that are variable in size,
like script and contents, will each have their own block. This is great
since most fixed-size properties fit in relatively small blocks of data (a
rect fits in 8 bytes, or if you are generous in 16, which would require
roughly twice as much space if you add the 13 bytes of housekeeping data
(block ID, data offset, block size, flags) to that. By keeping all small
properties in one block, the 13 bytes are divided between them, if you
will. If we have 10 properties, we only need a tenth of housekeeping data
per property. However, since mashing together all these data bits in one
block would mean we'd have to move around lots of data if their size
changed, I'm only doing this for fixed-size properties. User properties
will always be considered variable-size, as it is hard to anticipate how
the scripter will use them.
However, you will not notice all of this as a programmer, as XStackFile
already hides this fact from you. You just request a property, and it will
know where to look for it and how to get it.
What I am not quite clear about in my head is how the look-up of objects
by name or number will work. For numbers we'll probably have a list in
every bg, card and stack of the order of its sub objects which we can
search, but as names are stored with the object itself and not in its
parent, this will probably be a bit more costly. But I will very likely
hide this away inside XStackFile, because there streaming can be employed
to avoid loading all sub-objects of a card or stack just to look up one by
name.
Also, XStackFile supports multiple stacks in one file.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
_______________________________________________
Freecard-general mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freecard-general
