Solid API change request (with patch)

[Sebastian Kuegler]

Kevin, thanks for the explanation on the impact of this change.

On Friday 02 November 2007 10:48:14 Kevin Ottens wrote:
> 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&);

That makes it an easier transition, indeed. Together with the "there's most 
probably only one user anyway, with fix in the pipe", I think we should allow 
this API change.

> 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.

Understood.

> > 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.

I fully trust your judgement here, and I'm no longer opposed to this change.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071102/89e29716/attachment.sig>