Re: Linux Library Project, Game libraries

[Christian Reiniger <warewolf@mayn.de>]

Philipp Gühring wrote:

>I had the idea about a year ago, but nobody was interested back then.
>Perhaps you are interested:

Thanks. That's about exactly the same thing I envisioned for the new
PenguinPlay. Which means I *am* interested ;)

I thought quite a bit more on that matter lately and played around with
some models of how that thing could be done. My current favourite is a
close cooperation between PPlay and LGDC, looking somehow like this:

* The LGDC maintains a good database of available libraries and tools, just
as planned (at the end of the game is a sample table layout for this). That
should stay with the LGDC because it's the info game developers are looking
for.

* PenguinPlay does the main work on combining the libs and creating the
package, including hosting all the neccessary stuff. That's things that are
not that important to most game developers (in contrast to the library
authors), so we should keep that traffic from the LGDC list.

* The LGDC cares about the connection to the game developers, i.e. gathers
information about their experiences with the libs, about what they are
most interested in etc. Effectively most PPlay people will also be on the
LGDC list, so that will be more or less also PP work, but done via the LGDC
"interface" familiar to the game developers.

* PPlay also hosts the coding efforts of the little "missing pieces"
(supposedly primarily not-so-sexy infrastructure code). PenguinFile would
be an example of such a missing piece. Configfile/cmdline/... handling
would be another.


In this model LGDC and PP wouldn't really be seperate projects but
rather two "divisions" of one greater project  - one for game developers
and one for game *library* developers.

But perhaps this isn't optimal either...
What do you think?


>----------------
>I have the idea to create the "Linux Library Project". It should be a
>project like the Linux Documentation Project, which aims to
>coordinate all the Libraries that are available for Linux.
>What it should do:
>*Establish a platform for all the library developers to communicate.
>*Create a library package:
>  The kernel is package of all the drivers and the kernel
>  LDP is a package of all the manpages, infos, ...
>  So the Library should be a package of all the libraries.
>  We should collect all the libraries that are possibly intersting,
>bring them together, generate one big source-tree and precompiled
>versions for all platforms. So this would be a place, where problems
>with compiling on different platforms, problems with the dependencies
>of libraries, ... could be solved.
>The library package should be a distribution-independent package.
>We should enforce all major distributions (like SuSE, RedHat, ...) to
>just include the "Library package" into their distributions, so we
>should work together with them.
>When the enduser finds a game, or an application on the web, and he
>sees "libmikmod, glibc3.y, ... required", then the only thing he
>should have to do it to fetch the current version of the library
>package, precompiled for his architecture, install it, and then be
>able to play the game. We should give the library package a version
>number, so that they only have to say on an application: "Requires:
>Kenel 2.4.x (x>=4), Libraries >= 19991104, Computer >= 300 MHz".
>
>The LLP could be a platform to discuss Threading, i18n,
>architecture-differencies, .....
>What I want to be in there are all libraries from glibc, Xlib, ggi,
>Mesa, QT, Gnome-libs... just everything from /lib and /usr/lib.
>
>I have the idea, but I do not have the time and ressources to 
>realize this project, so I hope some finds the idea interesting, and
>realizes it.
>--------------
>
>I think it would be interesting to start the project out of the
>Linuxgames scene, because then we could integrate all our game
>libraries like SDL, ggi, ....... in the package, and they would be in
>the distributions earlier, which helps all the "game-developers",
>which depend on the installed libraries!


Here's the tables I'd suggest for the library database.

The stuff in <> brackets are the respective data types. 
int   = integer
line  = limited length, single line string
hlink = Hyperlink
xref  = DB-Crossreference
text  = variable length, multiline string

The stuff in [] are comments.


Table1 - libraries
------------------
<int>    ID number
<line>   Name
<line>   Current version
<hlink>  Current version's release notes
<xref>   Classification (-> Table3)
<hlink>  Homepage
<hlink>  Download location [what about mirrors?]
<text>   Short description
<text>   Library author's comment [?]
<text>   Supported platforms (Hw/OS combinations) [incl. comments (port
         status etc)] 
<text>   Underlying libraries [incl. comments]



Table2 - User comments
----------------------
<int>    ID number
<xref>   Library the comment is about (-> Table1)
<line>   "Subject"
<text>   Comment body



Table3 - Library types
----------------------
<int>    ID number
<line>   Type name
<text>   Some explanation text

[that lists things like "low level 2D lib", "Indoor 3D game engine" etc]



The interface to that should also make it possible to search the LGDC
site for 
* related news items
* articles mentioning the lib (reviews etc)
* tutorials talking about the lib
* games using the lib (can happypenguin help here?)



	Christian
--

Drive A: not responding...Formatting C: instead