0.8 and beyond

[David Edmundson]

(typical Dave sized email below. Sorry)


 - Libkpeople is getting a rewrite that won't have any of the current problems.

 Summary is:
  - Instead of storing all data in Nepomuk, we store a simple mapping
and sources provide data at runtime
  - PIM seem happy with this.

 Right now this is 90% feature compatiable with libkpeople0.1, Martin
and I have ported all the KTp stuff. Branch name is kpeople2
everywhere.

 I don't want this to be a thing that Martin and Dave work on
independant of the rest of the project and I would like more of you
involved.

 - Call UI

detrout is working on QtGstreamer1.0. This is amazing work, I'd like
everyone who wants to see an open KDE video service to help step up to
work on that.

 - Encryption.

 We want to support this so we can become the default IM client in KDE
SC from 5.0.
 The best approach I think will be to use libOTR4.

 In Kopete this is a plugin, whilst we have a plugin system in KTp,
ours has to be flexible enough to support the plasmoid and active -
which can't do the low level widget interaction needed for OTR.

 The Kopete code is basically:
  - some KActions in the chat kpart (see below!)
  - A singleton
  - some dialogs
  - message handling.

The message handling can fit quite well into our plugin system, the
rest not so much. I think we may have to compile it linked in to the
main chat-widget code, but I don't want to see spaghetti code spread
over everywhere.

 - KParts TextUI

There is some ongoing work to move the text-ui to use KParts. It means
we can embed chat in other apps, we can make that library private, as
well as simplify the code a lot as each tab can keep track of it's own
actions. I /think/ this is close to merging, but has a crash without a
patched kdelibs.. it would be good if we can avoid that.

 - QML Text UI

Please see here:
http://community.kde.org/KTp/Tasks/TextUIQML

The auto-scroll in the chat plasmoid (and therefore this) is the
biggest blocker.
Also please read my review and approve it.. :)

 - Singleton AccountManager/Factories
This A big API change, which will tidy everything up.
I always used to say we can't use a singleton AM because:
1) we don't want to fetch data for all contacts for all services
2) we don't want the same features for all channelFactories
doing so would result in /massive/ dbus overhead

[1] is fixed in GlobalContactManager which upgrades connections
[2] we can fix by using different channel factories in the different
client registrars.

If none of that means anything to you; just ignore this sentence.  :)

--- Timelines

I am currently thinking of merging kpeople2 code now-ish, entering a
beta freeze, and releasing 0.8 soon after (i.e mid December). I know
that doesn't leave a lot of time for other new features, but I think
it's worth fixing this metacontact stuff ASAP. We can always release
0.9 soon after.

I want your input on this; I don't want to dictate the project.

David