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 | dvra...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel