Re: API freeze release ... status so far.

[Christian Schaller <Uraeus linuxrising org>]

On 03 Aug 2001 08:13:52 -0400, Michael Meeks wrote:
OK, lots of debate on this issue while I was at work, but here I go :) I will 
comment on the issues pointed out by other people after I reply to Michaels 
original message. 


>         Also - I hear rumours of GStreamer being used as a sound API - and
> I wonder:
> 
* Who uses this API
Not that many, the GStreamer API is still not 100% ready since the event
system is still missing. Erik Walthinsen is currently working fulltime
on the event system. I can't give a accurate timeframe for this except
'very soon', but I will have Erik mail the list with some more accurate
timeframe estimates later.

That said, even with the API not 100% done we still have quite the
number of applications under development using GStreamer including
Rhytmbox (an itunes clone), Bonobo-media (bonobo support by Erdi Gergo),
a Mozilla/Galeon plugin, gnonlin (a nonlinear video editor),
gstmediaplay (our media player), Kino (Digital Video editor) and I think
around 6 -7 others in different stages of development.

>         * Where is the API published ?
On Gstreamer.net there is API documentation.

>         * Is it frozen ? / can it be frozen now ?
No, it is not currently frozen cause there is still some things needing
to be commited, for instance the event system. To what degree we can do
a freeze of the existing API (meaning we promise to not change what is
there, but we will add sometings) I will leave that up to Erik to say.
Erik will probably available in 4-5 hours so I hope you can wait for his
reponse.

>         * Can we ship packages for it that don't require thousands of
>           obscure support libraries ?
Yes, the number of support libraries is directly tied to the plugins and 
not the core. Some of the functionality like .au and .wav support for instance 
do not depend on other libraries.

Problem with ditching everything that needs obscure support libraries is
that we lose support for most video formats that way. Wether that is
actually a problem in realtion to this API freeze is another matter.


Sander:
Regarding wether a decision to use GStreamer or not has been made. Well, no 
there has been no such decision made by whoever makes such decisions.
But historically such decisions seems to have made themselves, take for 
instance the adoption of Sawfish as the GNOME windowmanager which happened 
because it offered GNOME users something better/more integrated than anyting
else available and in the end 'everyone' used it and it 
was 'the GNOME windowmanager'. 
That is the aproach GStreamer is taking also, and considering
we don't really have any real competition I guess our sureness of being 
the GNOME 2.0 multimedia framework is quite natural. The only alternative
to GStreamer would be the current situation of no real multimedia support. 

And it is not only 'the GStreamer people' who seems to be so sure that GStreamer 
will be the GNOME 2.0 multimedia API. From reading comments made by core GNOME hackers
many of them seem to think so too.

Martin:
On aRts/CSL and its use. Well there are two different issues here and the one I 
feel you (and maybe everyone here but me) is discussing is the 'API to have 
applications say 'ding' at certain times. When I last proposed the use of GStreamer
in GNOME I got the comment that GStreamer would be overkill for such use. While I 
agree that a full multimedia framework might be a but much to enable apps to say 
'ding' I think that it would offer some advantages too, like full soundserver 
indepence. But the choice of using aRts/CSL as the 'ding' API does not preclude
using GStreamer as the basis for everything else which brings me to the 
second issue.

The second issue is that of the more advanced API for sound and video applications
in which I have yet to hear anyone not thinking GStreamer is the perfect choice for
GNOME. The GNOME-media applications is what of the current GNOME famility which is
natural to port to GStreamer based on this.

Another thing of to note here is that Martin's decision to adopt aRtsd might crash with other
parts of the GNOME 2.0 system. If I am not mistaken the accessibility work to 
adapt GNOME for use by the blind is using ESD. (Which is an example where using 
GStreamer for the 'ding' API too would be good idea, because if aRtsd is the best choice
for 'mr. average user' and esd has the needed functionality for blind users then
GNOME can easily acomodate both cases using GStreamer as the API. 

---
As an end comment I would say that GStreamer really want to be considered a
part of GNOME and I think having GStreamer as part of GNOME is in the best interest 
of GNOME too, but even if GNOME for some strange reason decide not to officially 
embrace GStreamer we will survive, since I am quite convinced that we 
will be the de-facto multimedia framwork no matter what the official policy is :)  

Anyway, Erik will hopefully be able to give you a more detailed report on the 
issue of API freeze, general timeframe etc.

Christian