[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kwallet binary compatibility
From:       Michael Leupold <lemma () confuego ! org>
Date:       2008-08-22 7:05:10
Message-ID: 200808220905.10363.lemma () confuego ! org
[Download RAW message or body]

On Friday 22 August 2008, Michael Pyne wrote:
> On Thursday 21 August 2008, Michael Leupold wrote:
> > Does that mean that I have to make a kwalletbackend2 and declare the old
> > library deprecated? (By the way, no client code will have to be changed
> > but the one in kwalletd - unless someone decided to use libkwalletbackend
> > directly).
> I would argue that unless it was made clear in the API that they were meant
> to be internal that the KDE_EXPORT implies they are public.

True. I think the backend is basically just excluded from doxygen to not make 
anyone else but kwalletd use it. But still someone else might have done that.

> In addition if applications linking against kwallet linked against that
> class (it's exported after all) then maintaining binary compatibility would
> mean that you can't break that class even if we do declare it as internal
> later.
> These are just my thoughts but I would run nm on like kwalletmanager or
> something and see if your classes are listed in there.

As far as I saw everything is exported - so I'll have to go ahead and create a 
second backend.

Thanks and kind regards,
Michael
[prev in list] [next in list] [prev in thread] [next in thread]