Re: [AD] Custom packfiles

[Elias Pschernig <allefant@xxxxxxxxxx>]

> >Without looking at the code - what are the problems?
> >
> At least the following:
> 
> (1) The chunk code requires the `flags' field in the PACKFILE structure
> to be properly set.

I see - and therefore all user vtable would need to deal with that as
well, making it much more complicated.

> (2) The chunk code uses the `hndl' field in the PACKFILE structure
> (which is a file descriptor) and does some dup'ing and seeking and
> stuff.  I didn't look at it too hard, but basically it assumes the
> packfile is a file underneath.

Yes, of course. And it has to insert special markers into the file as
well, hadn't thought about that. It's just, I'm using packfiles in my
safe file format, since I found it easy to be able to just skip
chunks. But I think now as well, they shouldn't be in the file vtable.

> >I think support
> >for pack_fopen_chunk should be there - else we can drop the feature of
> >file chunks completely.
> >
> Can't, they are used for datafiles.
> 

Yes, but probably they should be moved to the datafile layer then, and
be deprecated as file functions. (Only conceptually, with backwards
compatibility and all, there's not much that can be changed.)

> >At least, i would stop using them if it would
> >mean my custom file format using them can't be read from memory, for
> >example.
> >
> >
> 
> You can easily implement a similar thing using vtable packfiles if you
> have to, at least for reading and no Allegro compression.

Yes, just need to implement chunk markers containing sizes, and seeking myself.

> 
> If it's anything like packfile_password(), well, you've seen the
> problems we've had with that interface.  It's asking for trouble.

Yes, it would be better if the password could be part of the file
structure. Maybe the PACKFILE struct should get a user pointer? (Which
would be strictly a single user pointer, never to be used for anything
else, and always just one, not like DIALOG). If user vtables need
additional parameters (like e.g. a password or encryption key or
network information which can't be in the filename, or things like
that), it could point to a struct containing that info.
 
> Yes, that would be nice.  I might try it later.  From a user's POV it
> should make no difference.

Wouldn't actually require a state. pack_fopen always would open with
the old packfile vtable, and  all other file functions carry the
PACKFILE pointer anyway.