[AD] Todo?

[George Foot <george.foot@xxxxxxxxxx>]

On Mon, Oct 04, 1999 at 09:32:33PM +0100, Shawn Hargreaves wrote:
> I'm trying to figure out exactly how much work remains to be done before we 
> can call this a 4.0 final version, and came up with the following. Any 
> additions, removals, or other suggestions would be most welcome (and no, I 
> don't have any fixed timeline on this, just trying to decide how much stuff 
> needs fixing before we will be there).

Ten weeks later on, and it's just about there. :)


[General]

> George, if you are reading this: we were talking about inconsistencies with 
> nested datafiles and individual object access, but I forget what we decided. 
> Also, my todo list reminds me that I need to try to find some way of fixing 
> the fact that datafile password encyrption isn't very smart, and I have a 
> feeling that these two jobs might have a common solution. I'm not hugely 
> fussed about getting this done for 4.0, but it would be nice to sort out.

I don't remember what we decided; I looked through the messages
but only found a fragment of the conversation.  Here's what I
remember though.  The basic problem was knowing when an object
should be stored in binary form, and when it should be in
Allegro format.  I think we ended up talking about the notation
-- what does # mean, should the object referred to be stored in
binary format, is it any different to saying /, after there's
been a # already, etc.

Regarding the notation, I don't think there is a consistent way
to do it, and anything we do will break backward compatibility.
`datafile.dat#object' should definitely require `object' to be
in binary format.  When we write `datafile.dat#nested#object', I
think `nested' should be in binary format, but IIRC that's not
how it works at the moment -- `nested' has to be a non-binary
datafile.  Basically, I think `#' should associate to the left
-- `a#b#c' should mean load object `c' from datafile `a#b',
which is object `b' loaded from datafile `a'.  Currently I think
it works the other way.

My original suggestion was to store datafiles in binary format
always (which involves just writing an extra four bytes at the
start of the object -- a trivial patch, but a hack, which breaks
backward compatibility in pathological circumstances).  It would
cover up this bit of the problem, but it's not a fix, so maybe
the problem would recur in some way?

The other option, as I mentioned above (regarding associativity)
is to fix the nested datafile implementation, but this might not
be trivial because packfiles are essentially linear -- the
chunks of the nested datafile's objects are chunks at the top
level of the file, not within the nested datafile's chunk.  Is
that correct?

In summary, then, the current system implies that any object
after a `#' in a name should be in binary format, but the
implementation for accessing nested objects goes against this.
Hacking it to store datafiles in binary format works around
that; alternatively, the nested object implementation could be
fixed, which may not be trivial.


> I do need to fix some stuff to make it compile with gcc 2.95 and WARNMODE=1, 
> but that is just a matter of sorting out some warnings about structures that 
> are only being partially initialised (I wish gcc wouldn't warn about these 
> at all, but I'd rather fix it than ignore it).

I agree -- the standard defines how the rest of the structure
gets initialised, why should gcc warn about it?


[Windows]
> It would be nice, now that the code has stabilised a bit, to get Mingw32 
> building a native version of the DLL.

Was Henrik working on this?  It might be nice to do the same for
RSXNTDJ, which could be based on the same code to a large
extent.  RSX isn't totally free, though -- you have to release
sources only, or if you distribute binaries you must GPL them I
think.  It ought to be feasible in RSX too -- there's a link
from Delorie's `elsewhere' site to somewhere talking about
DJGPP+RSXNTDJ+DirectX.

> There is no MIDI support at the moment: how hard would this be to add?

I have a non-OPL sound card, so I could perhaps look in to it,
if nobody else is doing so already.

> Anything else?

I'm still not comfortable, but can't put my finger on anything
in particular that's bothering me.  Let's see how many things
break while you're away. :)


[Distribution]

Gorka wasn't happy about the current RPM system -- should we
change it?  Obviously we're just abusing RPM as if it were a
tarball+install script system, which I didn't think was too much
of a problem at the time, but he's said that it makes problems
with RPM's database of what (esp. binary) files are installed on
the system, and wrecks things like upgrades from one Allegro
version to another, and means that `rpm -qf' don't work
properly.  Here are the options, as I see them (maybe Gorka
knows of other options?):

 a) Leave it how it is, with all the problems above.  The
    advantage here is that everybody who uses RPMs at all knows
    how to install this stuff.

 b) Attempt to sort out upgrading from one Allegro version to
    another, by having, say, a common file called, say,
    `/usr/local/src/allegro-version', maybe containing the
    currently installed Allegro version, or just a witty joke.
    Then when someone tries to install a newer Allegro version,
    they'll get a conflict warning on this file.  I don't quite
    know how RPM upgrading (`-U' option) works, but I'm guessing
    that this would now be OK since it would uninstall the
    previous version before installing the new one?  Gorka?

    This isn't a total solution, it would just fix the upgrading
    problem.  We'd still have `rpm -qf' not working, and an
    incorrect RPM database.

 c) Do what Gorka has been saying, and switch to SRPM
    distributions.  We distribute .src.rpm files, which are
    sources of RPMs, rather than RPMs of sources. ;)  From the
    SRPM, you can generate a binary RPM (or several) especially
    for your system, which you then install.
    
    This is the Right way to do it; we get working upgrades,
    a correct RPM database, etc.  The only problem is that it's
    less simple to install now; it's really not very
    complicated, but for people who only ever install binary
    RPMs it might be a bit more of a problem because it's a
    break from what, for them, is the norm.

 d) Do (c) and also distribute binary RPMs.  But we don't like
    this option. :)

In my mind, (a) wins on the laziness factor, (b) on
functionality combined with laziness, and (c) on being Correct.
(d) loses all round, but it's possible that people like Red Hat
might want to do that sometime; if that's ever the case, then
it'd probably help a lot if we did (c).  However, I guess they'd
probably roll their own spec files if they wanted to do this.


George