Re: PFile notes

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>> I'm not sure I understand what you mean with that..
>> 
>Aha, a misunderstanding! :)

What about setting up an "Gallery of anecdotes" on the homepage, listing
all misunderstandings? And we'd need a picture of a gun... ;)

>> So placing the XHeader at the end again makes more sense, as it might
>> contain information about how the DirInfo part is laid out - and thus
>> should be written *after* that one.
>>
>Hmm... Agreed.

Too soon ;) My current favourite is placing the XHeader directly after the
normal header and specifiying that it always has to be "fixed" size.
Directory specific info should go into the directory data anyway.

Reason: example:

header	100bytes
content	100kbytes
dirinfo	500bytes
xheader	100bytes

Now imagine the content part grows by 20 bytes and the dirinfo part by
40bytes. The current dir serialization code simply writes to some stream,
i.e. does not write through the proper PakFile object. And that means the
PakFile object can't keep track of where the dirinfo part ends - and thus
it doesn't know where to start with the XHeader part.

The future, improved serialization scheme corrects this, but anyway. That
way we *really* can skip the "rewrite XHeader" thing. And we don't need the
"XHeader position" entry. All in all simpler.

>> The background is the following problem: When we add something to the Pak
>> we overwrite the start of the dirinfo part, but don't neccessarily reach
>> the end of the PakFile. That means we can't easily determine the start of
>> the (XHeader|DirInfo) part after such an op.
>>
>Why not? Taking the old start position of the DirInfo part and adding to
>that the length of the newly included pak should give us the new start
>position.

How do you know how much has been added if all write functions just take
the FILE pointer of the PakFile and write to it? All (content) write ops
have to be made via the PakFile object thus.

>Actually, its even simpler than that. Just take the stream position just
>after the content part has been added. That is the start position of the
>next part.

Too complicated. That way the writing code needs several special cases, and
needs to know where the content part ends - and has to update that info.
Only the PakFile object should know about that.

>> And the "relative" addressing is primarily a mechanism for abstraction and
>> easier understanding (keeping the parts independent of each other). Not
>> really neccessary, but nicer.
>>
>I still don't see how it helps.

Writing code outside of PakFile doesn't have to care about the size of the
other parts.


	Christian
-- 

Drive A: not responding...Formatting C: instead