activity API in experimental?

[Chani]

so... I'm starting to get people asking how they can use the activity API in 
applications - and in one case, in kdelibs.

on the one hand, I really want to help them get started on that, I want to 
have people using the API, giving feedback, and implementing awesome features 
:)
on the other hand... it's still changing, it's not ready for BC at all. it's 
experimental. Ivan's going to be making several changes to it this week, in 
fact.

I *could* tell them about the raw dbus interface (for which the api - 
KActivityConsumer and friends - is just a helpful wrapper), but that feels... 
icky. It's just as prone to change (only the errors wouldn't cause crashes, I 
suppose) and they'd have to rewrite it to use KActivityConsumer later.

we could, perhaps, move KActivityConsumer into kdelibs/experimental? if it's 
not too late? that would expose it without BC requirements (although the guy 
wanting to use it in kdelibs still couldn't, I expect?). I can't remember the 
exact implications of kdelibs/experimental, but 
http://techbase.kde.org/Policies/New_KDE_Library_API_Policy seems to imply 
that we just move it in there like moving to kdereview, and the only 
requirements are to version the library properly and have a cmakelists that 
can build it as its own project.

so, which is better for early adopters, a dbus interface or an experimental 
API? I'm leaning towards experimental, since it'll be less work for them to 
update their patches when the api does become stable.

-- 
Chani
http://chani.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101028/25104ebe/attachment.sig>