Re: [AD] Allegro generalization/extension mechanism

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


guilt:
> So, what do you guys feel/think/suggest about splitting up the library
> into base+implementation+extension?

I think that this makes a lot of sense for the structure of the library
internally, in as far as this is not done already (the bitmap loader, for
instance, already follows this approach fairly closely: the bitmap loaders
could all be made into addons by simply removing the code from the library,
packing it seperately and recompiling). But this is something that I think
has been discussed and agreed upon before now.
Wether it makes sense to offer base and implementation as a seperate
download is debatable, I think. I tend to think not.

Chris:
> I probably would leave Allegro as-is (eg. one full-featured library),
> and provide some kind of public plugin API for 3rd party add-ons.

Yes, I think this is the way to go too.

> And I don't see the use in splitting Allegro up, since if the Allegro
> devs are going to work on/support it, it might as well be in the lib
> itself and reduce the amount of dependancies the user has to worry
> about.

Good point.

> Things like the GUI, if work on it is going to be stopped, I can
> understand being externalized into a plug-in and letting someone else
> take it over.. but something like image loading that's going to be used
> alot and would be maintained, there's no reason to externalize.

I tend to agree. There was also a lot of discussion on this topic on
Allegro.cc when Korval first proposed `AllegroPro', which at its base
wouldn't have image loading and file I/O either. What good is a library
that has no way to load external resources, or needs an addon for
everything you want to do with it?
Currently, Allegro needs addons for loading certain filetypes (PNG comes to
mind) because it is older than those types and it contains loaders that are
no longer useful (LBM, if that was ever really useful). If Shawn were
designing Allegro today, I think it would include PNG loading by default.
This isn't an addon because it's best that it's an addon, but because
Allegro's design makes this more convenient.

The discussion wether or not Allegro should include PNG support by default
in a post 4.2 version is a different one. This will make Allegro dependent
on zlib and libpng. On the one hand, it is convenient to have Allegro
depend on as few third party libraries as possible. On the other hand,
Allegro already requires DirectX in Windows to build at all and
X11/SVGAlib/whatever in *nix to build a fully usable version. Adding zlib
and libpng wouldn't be a big deal for the UNIX port, but it might be for
Windows. Of course, the advantage would be the ability to use zlib for
packfiles as well.
Anyway, that is a discussion best left until after 4.2 is out and 4.3 is
well underway and maybe has seen its first release.

Evert




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/