Re: [AD] Allegro generalization/extension mechanism

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


My arguments are in the favour that.. if one has to add/update support
for image loading and fix it later, it wouldn't still affect the
blitting etc. parts of the API .. and, by separation, it could just
extend the usability of the library.. like, if Allegro could support
AVIs than just FLICs or OGGs than just VOCs and WAVs, or PNGs than
just LBMs .. :)

On Mon, 14 Mar 2005 04:36:13 -0800, Chris <chris.kcat@xxxxxxxxxx> wrote:
> guilt wrote:
> > So, what do you guys feel/think/suggest about splitting up the library
> > into base+implementation+extension?
> 
> 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. The
> Allegro devs could sanction/endorse certain plugins, but since
> they're/we're not going to maintain it, it wouldn't go good in the lib.
> 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.
> 
> 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.
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
> 


-- 
Karthik
http://guilt.bafsoft.net




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