Tim-Philipp Müller schrieb:
> On Sat, 2009-09-26 at 22:54 +0300, Stefan Kost wrote:
>
>>> videosignal: change pattern data type to uint64, add property and message field
>>>
>>> Keeps the old uint typed value support for compatibility.
>>>
>> This element is in plugins bad. I think its fine to just break the API. If
>> people use this for real, then they should push that it goes to good :)
Actually, _I'm_ using it for real of course, and this is the best way of
breaking the chicken-and-egg situation for me :)
> Well, you're right of course, but for elements where we know that people
> are using them already and where it costs us hardly anything to keep
> things backwards compatible, we should do that IMO. We can then remove
> the deprecated API after a while or when the element is moved to -ugly
> or -good.
>
> And we really shouldn't ever change API in a way that may lead to
> crashes for users of the old API (as changing a property from uint to
> uint64 type without changing the property name might, for example).
Works perfectly here since I believe the property name and message field should
really keep the *-uint64 name in the long term. There's some gotchas about
handling 64 bit integers in C, so I like putting a fat reminder about that
right into the API. Just think g_object_set (queue, "max-level-bytes", 0,
"max-level-time", 0, NULL), it looks so innocent :)
> Also, if we're not even trying to accommodate existing users of -bad
> elements where it's easy for us to do so, then people will just pressure
> us to move elements into -good prematurely. That's not something I'm
> particularly keen on.
>
> Cheers
> -Tim
--
Regards,
René Stadler
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Locked
