Re: [AD] Custom packfiles

[Elias Pschernig <allefant@xxxxxxxxxx>]

> 
> I don't see how it cuts down on duplicate code.  Say you're going to
> write a wrapper like:
> 
>     PACKFILE *load_wad_object(const char *filename, int index);
> 
> With your style:
> 
>     PACKFILE *load_wad_object(const char *filename, int index)
>     {
>        struct mystruct *data = malloc(sizeof *data);
>        data->filename = filename;
>        data->index = index;
>        return pack_fopen_vtable(&my_vtable, &data);
>     }
> 
>     int my_fopen(struct mystruct *data)
>     {
>        data->fd = open(data->filename);
>        seek_to_object(data->fd, data->index);
>        return ok;
>     }

Oh, there already is a ->userdata.. should have seen that before
writing the last reply.

> With my style:
> 
>     PACKFILE *load_wad_object(const char *filename, int index)
>     {
>        int fd = open(filename);
>        struct mystruct *data = malloc(sizeof *data);
>        data->fd = fd;
>        seek_to_object(data->fd, index);
>        return pack_fopen_vtable(&my_vtable, &data);
>     }
> 
> i.e. with my style pack_fopen_vtable() is only called after the rest of
> the opening process is complete.  You don't have to stuff input
> arguments into a struct just to get it through to pf_fopen.

The code duplication is more, if you want to support different file
types with the same code:

file = pack_fopen_vtable(can_be_any_different_vtable, data);
pack_fread(file, ...)
...
pack_fclose(file);

Now, this same code can work for different vtables, and the user
doesn't have to deal with the specifics (the vtable could come from
the .gz addon, or from the .tcp addon). And still, user code need not
call any gz or tcp specific functions. Just like we support different
bitmap formats.

With your way, I would need to have a different open function for
every file type, which must be selected e.g. in a switch. But that's
just what the vtable could do for the user.

> BTW, I found that if we drop support for old-style packfile encryption
> then the LZSS compression/decompression code can be completely decoupled
> from packfiles (I have done it in my local copy).  What do you guys
> think about that?  New-style encryption was introduced in 3.9.30.

I didn't even know there are different ones - but I would be for
dropping it - without  a compatibility layer. Just mention it in the
docs, and someone who needs to recompile something with old datafiles
simply can get version 4.1.17 and convert it. Is this related to the
old datafile format I've seen in the source? It must already have been
old around 3.12.. it can be dropped as well I guess. (As well as LBM).