Akonadi acting up (again)

Fri Sep 27 12:58:22 BST 2013

Sorry Kevin but I think you have missed the point on the not relevant aspect. Entire post this time really. They may be very relevant from a coding standpoint but not for a user other than one who says "Gee this uses an amazing structure and others are using it too so I don't care if it's slow or keeps having problems". :-) Maybe an extreme way of putting things but in essence what matters most? User experiences or implementation/structure if the latter spoils the former.

I am not saying that there is anything fundamentally wrong with the structure that is being used either. Just that there seems to be a significant difference in the performance aspects of email in KDE3 as against default email in KDE4. Maybe it's a Windows approach - ah well people will upgrade and Intel plus Moore's law will sort it out. I have noticed that in some ways a 2.6gh dual core plus 8gb of ram can struggle at times running KDE4. Perhaps the problem is not structure but implementation. Going on some other applications it does seem that C++ can have this effect. On the other hand this is not always the case. Makes me feel that there are 2 forms of writing C++ software, OOPs and OOP.  In terms of actual performance in the real world Moore's law is a bit dubious anyway.

Akanadi etc.

Yes different services. I new that there was some tie up but hadn't looked to see what it was. 

http://cmollekopf.wordpress.com/2013/02/13/kontact-nepomuk-integration-why-data-from-akonadi-is-indexed-in-nepomuk/

Interesting read linked to of the user basefrom here

http://userbase.kde.org/Akonadi

>From this it seems I may well be using KDE4 file indexing even with it turned off. Fine if so as it hasn't done any of the things I don't like. The problem with using inactivity as a trigger was demonstrated when it was forcibly used on SuSe to spin down the disks. As things stand there is no way of determining when an inactive period will end.

It also seems that if I really do disable indexing I may loose my digital clock and perhaps one or two other things. The clock sounds like someone thinking wouldn't it be nice to use .... to me. Hanging too much off a service may be a bad idea any way.

Me well I am not against change and also realise that windozy things are a mature technology. All arrangements boil down to some patch of screen with icons or the results of some application in it etc. Difficult to change really but things move on. :-) I sometimes think there are too many software people about with too little to do. On the other hand it's a frightening thought that a PC user such as my wife can do all she generally does on an iPad with a lot less power and sadly more ease. Speed - well printing does take some time to send the data but might not if airprint was available. In all other respects it's way way quicker to use than a net book for instance and just about does all of the things a lot of people want to do. My son bought me one for my birthday and I have to admit it's the most definite step forwards I have seen in a long time even with it's limitations which in practice for many people are few.

John

----- Original Message -----
> From: Kevin Krammer <krammer at kde.org>
> To: kde at mail.kde.org
> Cc: 
> Sent: Tuesday, 24 September 2013, 18:33
> Subject: Re: [kde] Akonadi acting up (again)
> 
> On Tuesday, 2013-09-24, John Woodhouse wrote:
>>  ----- Original Message -----
>> 
>>  > From: Kevin Krammer <krammer at kde.org>
>>  > To: kde at mail.kde.org
>>  > Cc:
>>  > Sent: Monday, 23 September 2013, 18:26
>>  > Subject: Re: [kde] Akonadi acting up (again)
>>  > 
>>  > On Monday, 2013-09-23, John Woodhouse wrote:
>>  >>  :-) I'll refrain from commenting on OOPsers ideas on 
> modularity and
>>  > 
>>  > code re
>>  > 
>>  >>  :use and have never looked to see how it's organised so 
> shouldn't.
>>  > 
>>  > On the
>>  > 
>>  >>  :other hand why such a difference between Kmail 3 and 4.
>>  > 
>>  > Not sure what OOP refers to here but I assume it doesn't mean 
> Object
>>  > Oriented
>>  > Programming.
>> 
>>  Afraid it does - when things look to have gone wrong I hope it catches on.
> 
> I actually assumed it meant that, but since it didn't make any sense in the 
> context it appeared in I found it better to ask.
> 
> The server/client based architecture made reusable components more viable but 
> that is the case independent of the client side programming technique/paradigm 
> being used. 
> 
> For example previously it wouldn't have been worthwhile to invest into 
> separating the email viewer into a component since email backend access is a 
> rather tricky business.
> By not needing to do that anymore in each client it became a viable goal to 
> create a library for email viewing functionality.
> As a positive side effect it becomes more viable to consider alternative 
> viewers, since the separation reduces implicit coupling.
> 
>>  > Akonadi, like Evolution Data Server (short EDS) before [1], is a 
> service
>>  > oriented approach to PIM data access.
>> 
>>  In some ways that comment isn't relevant.
> 
> I was just clarfying that the change wasn't about programming paradigm but 
> architectural.
> And that similar projects are arriving at very similar architectures due to 
> similar requirments.
> It's just to show that given the same requirements and constraints, arriving 
> 
> at very similar solutions isn't mere conincidence.
> 
>>  > I am also not sure which two versions of KMail the second sentence is
>>  > referring to. Is that KMail based on Qt3 and one of the two versions 
> of
>>  > KMail based on Qt4 or KMail1 and KMail2?
>> 
>>  Help Kmail about for the one I am using from kdepim3 shows Kmail 1.9.10
>>  using KDE3.5.10 "release 67"
>> 
>>  The KDE I am running shows KDE Platform Version 4.10.5 "release 
> 1"
>> 
>>  I assume the releases in bunny rabbits relate to OpenSuse. I'm fairly 
> sure
>>  other QT4ified Kmail's from KDE3 may be available elsewhere as well.
> 
> I was asking because there have been changes between the Qt3 based version of 
> KMail and the Qt4 based one, as well as changes between version 1 of the 
> application and version 2.
> 
> The differences between the first two is mostly a result of changes in the 
> underlying libraries. Some of those were more involving than other, so the two 
> code bases are not identical. But considering the size and age of the code 
> base changes there can be considered rather limited.
> 
> There were more significant changes between versions 1 and 2 of the 
> application, due to the architectural nature of the changes below.
> For example synchronous and asynchronous data access require very different 
> handling. Sometimes it is viable to hide the difference in some way, sometimes 
> it isn't and it becomes more viable to specifially address the difference, 
> leading to a more significant change.
> 
>>  Must admit I may have a jaundiced view of Akonadi. This goes back to when
>>  it was introduced. Appeared to slowly scan my disks to index them. I shut
>>  it off after a several days. Fed up with disks tinkling and concerned
>>  about wear. It should have quickly got out of the way if I needed to use
>>  the disk and didn't. Very noticeable pregnant pauses instead. 
> 
> I think you are referring to a different service there: Nepomuk.
> Quite some improvements have been made to its operational behavior over the 
> last couple of releases.
> 
> Cheers,
> Kevin
> -- 
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring
> 
> ___________________________________________________
> 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.
> 
___________________________________________________
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.