split kdepimlibs

[Daniel Vratil]

On Tuesday 26 of August 2014 12:32:48 laurent Montel wrote:
> Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit :
> > On Tuesday 26 August 2014 11:20:25 laurent Montel wrote:
> > > Hi,
> > > I will split kdepimlibs as it
> > > 
> > > akonadi (need to find another name because it's still used)
> > > akonadi-abc
> > > akonadi-calendar
> > > akonadi-contact
> > > akonadi-mime
> > > akonadi-notes
> > > akonadi-socialutils
> > 
> > To me it sounds like some of those things could be regrouped now. What
> > about also bringing the akonadi server on board? Having a bigger akonadi
> > framework containing server (right now in kdesupport), some access libs
> > and a few default plugins would make sense (it looks like a KIO like
> > framework).
> 
> Regroup as a framework as :
> akonadi-framework (better name)
>  -> src
>      -> akonadi-abc
>      -> akonadi-calendar
>      -> akonadi-contact
>      -> akonadi-mime
>      -> akonadi-notes
>      -> akonadi-socialutils
>      -> server (Dan must speak about it if he wants to move here)
>      -> plugins serializer (moved from kdepim-runtime)

Hi,

I definitely want to have the Server and the client libraries in one repo, 
shipped as a complete solution for PIM storage with the server being just part 
of the solution, not a standalone one. My original idea was that we would just 
merge the client libs into the existing akonadi.git repo, but setting up new 
akonadi-framework.git works just fine with me (and akonadi.git end up like 
kdelibs.git)

About the type-specific (-abc, -calendar, ...) frameworks: maybe there could 
be something like Akonadi Framework Extras, and Akonadi Framework would really 
only be the server and the base client libs? What do you think?


Dan


> 
> > > gpgme++
> > > kabc
> > > kalarmcal
> > > kblog
> > > kcalcore
> > > kcalutils
> > 
> > This one looks like a dumping ground of random things. Maybe some of it
> > should move in other frameworks?
> 
> Sergio can speak about it
> 
> > > kholidays
> > > kimap
> > > kioslave
> > 
> > Definitely not a framework. Are all the ioslaves in there still used? I
> > think at least some of them can be let go. The others could go in
> > kio-extras I guess.
> 
> kioslave indeed not a framework. I think that just pop3 is used by kdepim
> 
> yes others can move to kio-extra
> 
> > > kldap
> > > kmbox
> > > kmime
> > > kontactinterface
> > 
> > Probably should go in kdepim or kontact itself. Similarly the content of
> > the kdelibs/interfaces folder moved out of KF5.
> 
> We extracted it in 4.x to allow to create kontact plugins for other
> application.
> If we merge in kdepim we will not able to do it.
> 
> > > kpimidentities
> > 
> > Maybe deserves a better name? kidentitymanagement?
> 
> Ok seems better. I will work to rename it.
> 
> > > kpimtextedit
> > 
> > I suspect it could get a better name, but couldn't decide yet. :-)
> > Also I wonder if some of it could/should go in ktexteditor? But I don't
> > know the respective feature sets enough to be sure.
> 
> For me it's kdepim specific.
> 
> > > kpimutils
> > 
> > Looks like another dumping ground of random classes. Each class should
> > likely find a new home.
> 
> Ok I will try to move them.
> 
> > > ktnef
> > > kxmlrpcclient
> > > mailtransport
> > > microblog
> > > qgpgme
> > 
> > Couldn't that be merged with gpgme++? This one already builds several
> > variants depending what it finds on the platform, why not treat the Qt
> > integration in the same way?
> 
> Really I never study this lib, there is not unittest, I don't know how it
> works and I don't know why there is several build.
> I will not work on.
> 
> > > syndication
> > > 
> > > is it ok for you ?
> > 
> > I tried to point out things which would be harder to address after the
> > split. So I think we should have discussions and decisions about the
> > points
> > above before being able to proceed.
> > 
> > Regards.

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140826/d23346a2/attachment-0001.sig>