Source Compatability and DCOP

[Ian Reinhart Geiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 07 August 2002 11:23 am, Cornelius Schumacher wrote:
> On Wednesday 07 August 2002 16:40, Ian Reinhart Geiser wrote:
> > 	I noticed KAddressbook changed its dcop interface in a Source
> > Incompatible manner.  This i guess broke KPilot, but worse it seems to
> > have broken a few scripts I had done for a client for adding information
> > to their addressbook from my TWIG web mail interface.
> >
> > 	Is there a policy on breaking DCOP interfaces on sub releases?  Is the
> > fact that KAddressbook is not in kdelibs make it okay to change on
> > subreleases? Is it too late to fix this problem?
>
> The problem with KAddressbooks DCOP interface was that it exposed internal
> data structures. These were completely changed for 3.1, so there is no real
> way back.
>
If the new address book where not so good, i would have much harsher words for 
that plan of attack ;)  But as with all OOP just because its internal dosent 
mean you cant expose it, you just need to write more code...

> Which DCOP calls did you exactly use? Perhaps there still is a chance to
> fix the problem.
>
I tried to look at the code, but got kinda confused.  I have been using the 
following dcop interfaces:

QDict<ContactEntry> getEntryDict()
void addEntry(ContactEntry newEntry)
void changeEntry(QString key,ContactEntry changeEntry)
void removeEntry(QString key)

I am assuming that ContactEntry no longer is public, correct?

Is there a way we could make ContactEntry a dcop ref with a dict interface?

> As far as I know there is no policy on DCOP interfaces, perhaps we really
> need one. It might also help, if DCOP interfaces would support some kind of
> versioning.
I am pretty sure versioning would do no good here, as there is no older fall 
back interface.

Either way it looks like I am SOL here, but maby its for the best.  Maby in 
KDE 3.2 we can have a better dcop interface that will allow data access 
again.  For me the biggest part is data access, thats a real showstopper.  
After that names are just an inconvenence.

What is your idea about offering an alternate interface and then a migration 
path?

Thanks
- -ian reinhart geiser
- -- 
========================================
Everyone talks about apathy, but no one ____does anything about it.
========================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9UUcRPy62TRm8dvgRAsddAJ9bGahNSUAIOLPyp50b5Vd5C7p/6gCgsOSB
W0ux5DJkb43w9dNN791Czxo=
=4cCV
-----END PGP SIGNATURE-----