[Kde-pim] PIM Libraries Shuffle (Was: License changes)

[Tom Albers]

Op ma 25 jun 2007 21:27 schreef u:
> On Monday 25 June 2007 01:36, Allen Winter wrote:
> > On Sunday 24 June 2007 4:58:03 pm Ingo Klöcker wrote:
> > > On Sunday 24 June 2007 22:16, Allen Winter wrote:
> > > > Unfortunately, due to the library dependencies, relicensing and
> > > > moving libkpimidentities to the kdepimlibs won't be possible
> > > > since that library depends on libkleo.
> > >
> > > It should be pretty easy to remove this dependency. It's really
> > > only Kleo::CryptoMessageFormat. I propose to make KPIM::Identity
> > > extensible with custom properties (QVariantMap). Then the preferred
> > > crypto message format could simply become a custom property that is
> > > known to Identity as a simple QString or QByteArray. The conversion
> > > from
> > > QString/QByteArray is then simply done with
> > > Kleo::stringToCryptoMessageFormat() where the value is actually
> > > needed.
> > >
> > > In fact, we could convert a lot of the more esoteric properties to
> > > custom properties, e.g. m*Key, mFcc, mDrafts, mTemplates,
> > > mTransport, mDictionary, mXFace, mXFaceEnabled, mBcc. This would
> > > make the interface much nicer and more generic.
> > >
> > > Sounds like a nice little junior project.
> >
> > Yes, I like the re-architecture.
> >
> > But doesn't this still give us LGPL code (libkpimidentities) which
> > depends upon GPL code (libkleo)?
> 
> No. libkpimidenties will no longer depend on libkleo if the 
> Kleo::CryptoMessageFormat member variable (and the other variables I 
> mentioned) is replaced by a simple QVariantMap. Only code (e.g. KMail) 
> that wants to store/fetch the crypto message format in/from a 
> KPIM::Identity would have to link to libkleo in order to be able to 
> convert the crypto message format that is stored as QString or 
> QByteArray in the QVariantMap to the actual value of type 
> Kleo::CryptoMessageFormat.
> 
> KPIM::Identity gets two new methods
> 
>   QVariant property( const QString & key ) const;
>   void setProperty( const QString & key, const QVariant & value );
> 
> (yes, this looks a lot like QObject's property() and setProperty(); 
> maybe we should even use exactly the same interface as QObject, i.e. 
> const char * instead of const QString & and bool instead of void, to 
> avoid confusion) and in order to set or get the preferred crypto 
> message format one would call
> 
>   ident.setProperty( "PreferredCryptoMessageFormat",
>     Kleo::cryptoMessageFormatToString( preferredCryptoMessageFormat ) );
> 
> resp.
> 
>   preferredCryptoMessageFormat =
>     Kleo::stringToCryptoMessageFormat(
>       ident.property( "PreferredCryptoMessageFormat" ).toString() );
> 
> 
> Obviously, the key "PreferredCryptoMessageFormat" (and all other keys) 
> should be stored as static const somewhere (shared by all interested 
> apps) to avoid typos..
> 
> Regards,
> Ingo

Hi, 

I just committed a patch which implements all above. I've attached the diff.  I've converted all internal variables to use a QHash<QString,QVariant> and added new setters and getters. I've kept the old-style getters as convenience functions. 

I've tried hard to understand why things were done the way they were written and changed them to QHash functions. The class took care of the == operator, so it had to set variables to empty, so it could compare identities correctly. I tried to not break this.

Comments are welcome. The patch to change kdepim to use this lib in kdepim is ready and sitting locally until I know I won't interfere with anyones work at akademy.

Toma



-------------- next part --------------
A non-text attachment was scrubbed...
Name: kpimidentities.diff
Type: text/x-diff
Size: 27231 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070630/971a9e6f/attachment.diff>
-------------- next part --------------
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/