| |||||||||||||
The cake, it was a lieThe cake, it was a liePosted Sep 25, 2012 10:22 UTC (Tue) by jospoortvliet (subscriber, #33164)In reply to: The cake, it was a lie by obi Parent article: GStreamer 1.0 released
So you're saying that porting once every 7 (!!) years, is more painful than writing and maintaining the abstraction layer? Well, if all the technologies behind you are changing each every 7 years, yes, you're changing all the time. And that's the case with applications build on gtk etc - they get left behind quickly once active development stops. That is where a proper abstraction provides benefit: take away work from application developers, increase lifetime of applications and group changes to them. For example in the Qt ecosystem you go through a minor change every 4-5 (Qt 2-3, Qt 4-5) and a big one (Qt 1-2, Qt 3-4) every ~8-10 years. At that point you do one port and you're good to go for that long (plus that the 'old' framework stays around for another 5 or so).
(Log in to post comments)
The cake, it was a lie Posted Sep 25, 2012 17:10 UTC (Tue) by ovitters (subscriber, #27950) [Link]
Qt is at version 5, Gtk+ is at version 3. I'm not really seeing the comparison. Seems to be pretty ok for something that maybe has 1% of the developers. Glib is at version 2 btw.
The cake, it was a lie Posted Sep 26, 2012 4:49 UTC (Wed) by khim (subscriber, #9252) [Link] Well, if all the technologies behind you are changing each every 7 years, yes, you're changing all the time. Only if you use CADT model. The fact of the matter: MacOS, Windows, other platforms regularly redo all the levels of stack - yet somehow people can use all these creations without additional layers of indirections. Why? Oh, it's easy: yes, they change "state of the art" once per about five-to-seven years, but they continue to keep supporting older methods, too. Exactly like GStreamer is doing. I can see the pluses of an indirection layer for something which changes regularly and forces you to port everything right away, but for something like GStreamer where upstream is sane and seriously thinks about maintainability... this is just an additional complication.
The cake, it was a lie Posted Sep 26, 2012 12:22 UTC (Wed) by sebas (subscriber, #51660) [Link]
Upstream simply does not satisfy KDE's requirements for binary and source compatibility, namely BC and SC across a major release lifecycle.
GStreamer's BC and SC have been broken more than once since KDE 4.0, which means we (and every developer using the KDE platform) would be stuck with old and unsupported versions.
That's the exact opposite of maintainability.
|
|||||||||||||