Re: [AD] Possible new features for Allegro?

[Hein Zelle <hein@xxxxxxxxxx>]

Vincent Penquerc'h wrote:

> In reply to the thread in general:
> 
> I'm sounding like the devil's advocate, but I don't see the
> problem with what some call the "Allegro bloat". 

Ah good. I was getting afraid noone would object :-)

> The trouble
> I have with bloat is when stuff is interdependant, or slows
> down the main stuff. You shouldn't pay for what you don't
> use, but that's no reason to put everything aside because
> you think the number of things you already have in the lib
> is too high. It would matter only if these things were so
> entangled that changing one would require changing the others.

Technically you're completely correct there. Somehow, and this is
probably very subjective, it feels 'wrong' to me though that if I
would not want to use allegro-net because it doesn't do what I want, I
would still need to 'have' it even though I'm using a different
library for networking. On the other hand, if everything works as it
should there is no problem: extra code is on your harddrive but
nothing else. I'm wondering if that goes for shared libraries too,
though: does a .dll or .so file get loaded completely or only the parts
that are used? I always thought they were loaded as a whole...

> Sure, there is quite a bit of interdependant stuff at the
> moment, but it doesn't mean adding, say, networking, would
> add more. Networking would get dependant on some of Allegro's
> stuff, but not vice versa. De-entangling stuff would be nice,
> but, as long as candidates for addition are not too esoteric
> or non-standard or similar "qualities", and that they are
> useful for game programming, I see no reason to deny them
> without another reason.

I see only one which has been named a couple of times: if you put
something into allegro it has to be of the same (very high) quality,
and it has to be maintained even if it isn't used (anymore). Putting
things in separate packages makes it much easier for the core allegro
developers to not spend energy / time on it, and it is also easier for
the package maintainer because they have more freedom, as George
mentioned. 

Of course this is somewhat contradictory with my proposal: the
'official' allegro parts (graphics loading, sound etc) will still need
this quality, the maintenance and the discussing on the mailing list,
so there nothing much changes. For add-ons I think it would be a big
improvement though if download, API (perhaps ABI) and make system
would be part of allegro.

My latest attempt to build galeon (lite-version of mozilla) at work is
a nice example of why I think this system could be an improvement, and
also a disaster if done wrong. I had to download mozilla (huge). I had
to build it (took 8 hours or so on my O2 workstation), and after that
Galeon only uses the *&@(*$^# graphics engine! (about 1/10th of
everything I downloaded and built).  Next, Galeon requires GNOME to
build, which is not installed on my O2. I go to pickup GNOME. Gnome
consists of about 7 packages (or more, I'm not certain I had all
required packages!), each with a (different!) separate
build-installation procedure. At the fifth library I try to build and
install (Orbit) I get an error in a configure script which I don't
know how to fix. I gave up.

I now had 500 (!!!!) mb of harddrive space in use (on an always full
2G drive) for just building Galeon, and after spending 1.5 days at
work building it, it fails on a sub-part, an add-on.

I realize allegro is nowhere near as bad as that (it's even very
good), but this would be my worst nightmare for it to become. I think
that whatever is done, some points should be taken care of:

- The core of allegro should remain very well maintained and of high
  quality, as the library is now. This is perhaps the most difficult
  to achieve with lots of separate add-ons.
- extra modules / add-ons should be available in an _easy_ manner and
  in _1_ location for ignorant users who have _no_ idea of where to
  get such things. (you don't want to know how much time this ignorant
  user spent on getting mozilla :-)
- there should be 1 (and only _1_) installation procedure, if at all
  possible.
- double / unused code should be avoided to reduce download / build
  times and hard drive space.

Thanks for the criticism Vincent, you make some good points.

Hein Zelle

>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
 Hein Zelle                     hein@xxxxxxxxxx
	                        http://www.icce.rug.nl/~hein
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<