| Re: [AD] Custom packfiles |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] Custom packfiles
- From: Elias Pschernig <allefant@xxxxxxxxxx>
- Date: Sun, 2 Jan 2005 02:22:57 +0100
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=dTsMzOoncTnRsifrCjGnBC231qoheNkUQgds3QTkCK8NwyAlhquAqzQzlQhuuR9iLl27mLoRjsok5XEAAsE1NYbR2R4Hj9kbr4dnWgJ8rJIjCGEeuVKLfn4PKkNh8vi1aaeqq0nrrZPZ1yJKu/1VYko3SPD3UhBtf2Qf7fMdFlo=
> file = pack_fopen_vtable(can_be_any_different_vtable, data);
> pack_fread(file, ...)
> ...
> pack_fclose(file);
Was just thinking some more about if "open" should be in the vtable or not:
If it is, some things can be easier for users:
pack_fopen_vtable(tcp_vtable, "192.168.0.1:1234");
pack_fopen_vtable(gz_vtable, "blah.txt.gz");
Obviously, these examples would pass the 2nd argument as filename to
the open function in the vtable, which then would initialize the
->userdata member of the PACKFILE with its relevant data. Everything
stays simple for the user.
OTOH, the expackf.c can't be done that way, since memory files need
more than a single string argument from the user. The best way
probably would be to modify expackf.c so it has a PACKFILE
*memread_fopen(unsigned char const *address, long length) function.
And addon authors could then provide algz_fopen(...) or
altcpfile_fopen(...) like above - but no vtable entry. I still find it
somehow asssymetric to have no fopen entry though..