Solid API change request (with patch)

[Kevin Ottens]

Le vendredi 2 novembre 2007, Sebastian Kuegler a écrit :
> I'm against changing the API if it doesn't fix a bug in this stage. To be
> able to judge this issue in a more informed way:
>
> - Is it possible to do this in a binary compatible way (which doesn't make
> one puke when reading the code)

Well, it's a signal signature change. So binary compatible... Granted it means 
the connects of non-ported code will fail at runtime though. A way to avoid 
this problem would be to add the extra signal (bool,QString) instead of 
replacing the current one. Solid::StorageAccess would have:
void accessibilityChanged(bool);
AND
void accessibilityChanged(bool, const QString&);

Note that I'm not really in favor of this move though, despite the RC being 
already released.

> - How painful is it shifting this to post-4.0?

Depends on who use the API. In the case of Jeff it makes his feature more 
complicated to write, keeping around a lot of pointers and allowing him to 
shoot himself in the foot when a user upload stuff to his portable media 
player. Also after 4.0 modifying a signal like this will be a no-no on my 
side.

If we apply the proposal above (adding an extra signal instead of changing the 
signature of the current one), that means we'll keep two redundant signals 
until KDE 5.0.

> I think at this point we should only change the API for really critical
> issues, even if that causes a bit of temporary pain. We cannot introduce
> source/binary incompatible changes, that forces people to recompile and
> gives less time for testing, or it causes problems with BIC that need to be
> solved by a recompile and thus costs even more energy.

Note that solid is not widely used ATM. And this particular signal is used 
only by Jeff and KFilePlacesModel... Means that the transition won't be 
painful, Amarok dev already have the switch in the pipe, and the fixed 
KFilePlacesModel will arrive to you in updated kdelibs.

> IMO, this really is the time to only fix things, and not keep changing
> kdelibs. Besides that, introducing an API change after a release candidate 
> is ... not smart.

Timing issues in development have nothing to do with being smart or not. Maybe 
you didn't notice we're lacking developer time at a lot of places? That's 
really not tinkering at this stage, but new API defects getting detected by 
wider use.

> The platform is hard-frozen, and there's a good reason 
> for that.

Agreed, I wouldn't have okay-ed this change to Jeff if it could bite us for 
the transition, but since it was a signal signature change currently used 
only in kdelibs and by him it looks safe enough IMHO.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071102/47d0a999/attachment.sig>