[lsb-discuss] Looking at 4.0 work

[Sam Hart]

On Tue, Feb 12, 2008 at 5:01 PM, Wichmann, Mats D
<mats.d.wichmann at intel.com> wrote:
>
>  Jeff and I have been hacking away at the project
>  plan wiki page, bugs, and attendant detail pages,
>  and it's probably pretty different than what it
>  looked like the last time most of you scanned it,
>  so it's worth another look:
>
>  https://www.linux-foundation.org/en/ProjectPlan40
>
>
>  One interesting section is the section entitled
>  "Summary: Proposed Libraries".

Looking at these I see several of the core SDL (http://libsdl.org/)
libraries listed:
 * libSDL
 * libSDL_mixer
 * libSDL_image

I was actually an early contributor to and user of SDL (back in my
Tux4Kids days), and it doesn't seem like it would be an unreasonable
thing to add. libSDL is designed to be a thin layer, so additions to
the LSB wouldn't be excessive. It's API is stable- the last backwards
compatibility breaking change that I can recall was the alpha blending
semantics one which was over 8 years ago (see
http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fSetAlpha), and it is used
in many places where cross-platform multimedia is concerned.

Now, while libSDL is easy to argue for, SDL_mixer and SDL_image
aren't. They both have stable APIs to be sure, but both were
originally designed as sample libraries, examples of how you'd handle
things like image and audio file decoding. Of course, over time
they've practically become standards in that they are used everywhere
and even recommended. But the fact that they were originally intended
to be samples (SDL_mixer still says so in its description
http://www.libsdl.org/projects/SDL_mixer/) may be an issue.
Additionally, both SDL_image and SDL_mixer would pull in many other
libraries.

So, my two cents if these become desired/wanted for inclusion in the
LSB would be that libSDL would be okay, but SDL_mixer and SDL_image
may not be.