Tell who did you PAY to include Akonadi?

[Kevin Krammer]

On Saturday, 2012-03-31, Duncan wrote:
> Kevin Krammer posted on Sat, 31 Mar 2012 11:45:12 +0200 as excerpted:
> > On Saturday, 2012-03-31, Duncan wrote:
> >> Kevin Krammer posted on Sat, 31 Mar 2012 10:53:55 +0200 as excerpted:
> >> > http://www.betterinbox.com/
> > 
> > Yeah, they are a pretty new startup and obviously need to prioritze.
> > I was only aware of them because they are users of *and* contributors to
> > email related KDE libraries.
> 
> I saw mention of that on the webpage.  That /is/ nice! =:^)

Indeed :)

Btw, I believe that ksmtp is fully their work, so their contributions are more 
than just "a couple of changes here and there"!

One thing I forgot to write previously is that since they seem to use IMAP and 
SMTP, the client will likely also work with other mail service providers. 
Being a company they probably want their official documentation to only list 
ones they have tested with but not meaning that it doesn't work with others.

> > Something we will hopefully see more often when the frameworks effort
> > makes individual components more visible as stand-alone entities (which
> > they often already are, just not visible as such).
> 
> FWIW, I don't believe I've mentioned it yet, but while I wasn't
> particularly impressed with the kde sc rename

Yes, a concession towards the media, they like to have one name that addresses 
the whole portfolio :-/

The SC name is not needed if one refers to the products individually but the 
impression was that news outlets would not do that for KDE while regularily 
doing it for other vendors.

> I do like the idea as
> extended into (what I've read of) kde frameworks.  Between the greater kde
> modularization and the migration of some current kdelibs functionality
> into qt5 (which is from what I read itself tilting toward more
> modularization)

Qt4 is already quite modular, i.e. its libraries usually don't depend on each 
other (each one depending usually just in QtCore) and application developers 
can easily decide which ones to explicitly use.

My understanding is that on top of that Qt5 modularization is mainly changing 
how Qt is built, e.g. specialized libraries having their own repositories and 
not needing to be switched on or off when building Qt.

Not sure how much of a change in this direction we'll see from KDE Frameworks 
5, but I am not following it that closely so that might be applicable as well.

> , it sounds to me like a universally required kdelibs will
> be much smaller, and that it's going to be a better deal for users,
> distro-maintainers and kde devs all three, with more dependency
> flexibility and a more explicitly specified dependency chain, which
> should lead to fewer end-user visible bugs and less work trying to get
> the splits right at the distro level. =:^)

I am not sure it will make a difference for users since dependencies are 
handled automatically already anyway, but my guess is that the added 
flexibility will incur some extra cost for developers and especially packagers.

Right now application developers already specify which "frameworks" their 
application is using, e.g. whether it needs KWallet. However it is not 
necessary to make the build system search for them individually, their 
presence is satisfied by just looking for "kdelibs".

This then extends into the packaging realm, i.e. a kdelibs package satisfying 
the need for any application using whatever component.

Increased granularity will very likely make that a bit more complex, though I 
don't know whether it will be used at all levels (i.e. whether packagers will 
create individual package for components or just create a kdelibs package as 
usual).

> If the module releases are desynchronized as well, as I've read is being
> discussed, letting the modules evolve at their own rate, it could be a
> good thing.

True, but I don't think this will be employed anytime soon, at least not for 
the traditional modules. Faster moving products like Plasma on the other hand 
might switch to separately released libraries sooner.

> >> FWIW, there's also the still fairly new "trojita".  Qt4-based, but
> >> IMAP-only, unfortunately, which isn't going to help for users with
> >> POP3 (and webmail, but ugh!) providers only.  As I'm in that
> >> category...  But I'd be tempted if my providers did IMAP.
> > 
> > You could use it with a local IMAP server and use system level agents
> > for mail gathering, e.g. fetchmail.
> 
> I actually did think about it.  But decided that was biting off more than
> I could chew at that point, especially as I wanted off kmail for 4.7.0,
> which was fast approaching when I was doing my research.  Still, learning
> all about running my own mail servers, MTAs (mail transfer agents), etc,
> has for years been on my list of things I'd eventually like to try.  As
> I've learned stuff like how to run and configure my own md/raid, ntpd,
> dns, etc, and crossed it off that list, mail gets closer and closer to
> the top...

I can relate to that, I also never seem to find the time to look into these 
topics myself either ;)

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20120331/b3d8f0b0/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.