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

[Justin Kirby]

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?


-Justin



> > Moreover, I think it would be a good idea to extend the information to
> > a call for help. So do you want help and if so what kind of help
> > (testing, documentation writing or other relatively simple jobs, are
> > there programming jobs to be done etc) do you want.
>
> I think the main task aside of development will be documentation.
> Things will work differently with Akonadi, since no single application is
> in
> control of a certain aspect of PIM, e.g. KMail will be the GUI to mail, not
> the things sending or receiving it.
>
> While all functionality should be there just like it was before, common
> workarounds or usage patterns might no longer fully apply.
>
> Cheers,
> Kevin
>
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring
>
>
> _______________________________________________
> This message is from the kde-promo mailing list.
>
> Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set
> digest on or temporarily stop your subscription.
>
_______________________________________________
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/