[Kde-pim] [kde-promo] Akonadi questionez

Sat May 22 19:36:00 BST 2010

On Saturday 22 May 2010, Justin Kirby wrote:
> On Fri, May 21, 2010 at 3:21 PM, Kevin Krammer <kevin.krammer at gmx.at> 
wrote:
> > Hi Jos,
> > 
> > On Monday, 2010-05-17, Jos Poortvliet wrote:
> > > Hi fellow gearheads,
> > > 
> > > The marketing team asks for your help in communicating Akonadi.
> > > 
> > > You might all be aware of the questions often seen on
> > > mailinglists, like "what the heck does this resource hog do
> > > here" and similar insults. Basically, the users are asking:
> > > 
> > > 1. what does it bring me NOW
> > 
> > This is the hardest question, also because it depends on what "NOW"
> > refers to.
> > 
> > As of KDE SC 4.4 there isn't really a lot positive for users to
> > actually notice other than maybe access to Google contacts through
> > the Google connector.
> > Unfortunately this connector is limited in certain ways, e.g. which
> > contact fields it supports, so this might count more as a thing to
> > play with than a thing to work with.
> > 
> > As for KDE SC 4.5, well this for one depends on when in the 4.5
> > cycle KDEPIM
> > will be ready for release and it might also be just improvements on
> > certain data transports, e.g. I think there is a very functional
> > CalDAV connector which can talk to most calendar servers out
> > there.
> > 
> > Most of the time related to Akonadi had to be spent on massaging
> > insanely old
> > and complex code bases on top of something that is totally
> > different in almost
> > all aspects to whatever these applications had been using before.
> > 
> > So while an Akonadi based e.g. email setup as done with KMail2
> > could offer folder specific cache settings (current KMail can only
> > do account specific, same for all folder of an account and not
> > changable without account recreation), I am almost certain that
> > there is no UI for that yet. (somebody please correct me if I am
> > wrong on this one).
> > 
> > Other improvements such as not having to run KMail when working
> > with groupware
> > contacts or calendar such as Kolab is only visible to such users of
> > such setups, which probably means only a tiny group outside the
> > company/public administration camp.
> > 
> > > 2. what problems does it solve?
> > 
> > Right now mostly engineering problem such as getting rid of hack on
> > top of hack that where added during more than ten years of
> > development. It allows KDEPIM developers to look forward instead
> > of watching their backs,
> > allowing to cope with requirements that have been unseen at the
> > time applications like KMail or KOrganizer were designed first.
> > 
> > It also makes it possible to split things into more module parts
> > making it for
> > one possible for other application developers to do PIM related
> > stuff from withing their applications (e.g. sending reminder
> > emails from invocing applications) as well as enabling "light"
> > versions for use in mobile scenarios, etc.
> > 
> > > 3. what will it bring me in the future?
> > 
> > For one, more variety on data sources. We already see much more new
> > contributors working on Akonadi resources (data source connectors)
> > than at any
> > time before, mostly because working on these can now be done
> > without having to
> > muck with specific application code bases (see above).
> > 
> > Another one depends on whether other application developers will
> > use this non-
> > applications specific approach to enhance their applications with
> > related functionality.
> > 
> > Some early attempts have already shown potential for unprecedented
> > workspace
> > integration, context/activity aware new-mail notifications,
> > dragging PIM objects to your desktop but keeping them live-updated
> > and so on.
> > 
> > > Meanwhile, the promo team is struggling with this. We know *part*
> > > of the answer, but still would like to solicit input from those
> > > great minds which came up with it in the first place!
> > 
> > Unfortunately this is mostly something at developer level right now
> > as far as
> > improvements go.
> > A bit like in early Plasma days when people would complain about
> > things not working as expected and mainly developers-only
> > knowledge about what will be possible due to all the new
> > infrastructure thats in place now.
> 
> This might be a dangerous thing to ask but I'd like to play devil's
> advocate for a second.  If that is really true why are we fighting
> the idea of users not wanting it running by default?  If they're not
> a developer and there's no real end user benefit yet couldn't we
> instead focus on having distros make proper changes to leave it out
> by default until that situation changes?

That's exactly what we are doing for the upcoming KDE SC 4.5. kdepim 
will not be part of SC 4.5. Instead distros are asked to ship kdepim 4.4 
together with SC 4.5.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100522/f58dbb8e/attachment.sig>
-------------- 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/