[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Sv: Future direction of PenguinPlay



>I am opposed to the idea of wrapping existing
>APIs with our own API.
>
>It's just substituting one known, tested, working
>API with a fledgeling API.
>
In most cases, a 1-1 corrospondence between the wrapping API and the
underlying one should be sufficient.

>If you don't like the API presented by e.g. MikMod,
>Mesa/OpenGL, ClanLib or whatever, improve the API - don't
>wrap it.  That said, I don't know of anyone who is
>less than happy with the existing APIs for most of
>these components.
>
The point is that instead of having to learn 5-6 different APIs, you'll only
have to learn 1, even if this one of course will be somewhat larger.

Also, in this way, its easier to get the different libs to work together, as
they will all have a common interface.

On top of that comes the points of it being possible to switch underlying
libs without changing a line of code. So you can actually test all the
possibilities out with almost no effort.

>I think that portability is mostly a red herring in this
>case.  Again, most of these components are highly portable
>already, and if they are not then fix the component rather
>than clumsily retargetting the API (which rarely works well).
>
It would only be clumsy if it was done clumsily.

I doubt the different teams developing the libs would be very pleased with
us inserting features that served no porpuse but to make it easier for it to
interface better with PPlay. I doubt we'd be able to talk anyone into
changing the way they did streams or threads, for example.

Of course, we wouldn't *HAVE* to do that to get things working, but I
somehow really do not like the propect of having 6 different threading
models running concurrently. I don't think I'd want to use a lib that used 6
different threading models personally, and I don't think many other people
would.

The same goes for streams.

What about 2D/3D graphics? I sure would find it practical to be able to
manipulate the surfaces on my 3D objects using the 2D lib. Its kind of an
obvious thing that atleast I would take for granted. So, if I want an effect
running both in 2D and 3D surfaces (like a nice fractal water effect), I
have to write it twice?