Clarfications
|
| Author | Content |
|---|---|
| anda_skoa Feb 26, 2014 11:49 AM EDT |
Haven't read the other two threads yet, so some of that might already have been corrected. While it is certainly nice to read about history now and then, the reference to the recent Phoronix report made it look like it described the current situatuon. Maybe an update could add a clarification at the beginning of the article that the content describes a setup from a couple of years back, i.e. when file indexing was handled by Strigi. Readers find it odd that their systems do not contain the described components and look for missed updates, when in fact their systems are current. Btw, the reference to the Phoronix article made me laugh :-) You should rightfully be angry with them to post such nonsense and disguise it as an article. You are probably not alone who were lead to believe that the NEPOMUK research initiative and the Nepomuk-KDE software were the same thing. One must admit that is quite a feat on manipulative writing on Michael Larabel's part! Anyway, lets look at the article itself. One thing that is probably a misinterpretation of concepts and their relationship is that "KDE4's own email client, KMail, has now been modified by the requirements of the KDE "semantic desktop" so that it can no longer directly access the "maildir" folder where the emails are actually stored." The concept of indirect access through an arbiter is no related to semantic desktop at all. The requirements for semantic search could have also easily provided by KMail directly, in fact that is what Tracker does when KMail is the email program handling the user's email. I've already commented on the other article but a repetition cannot hurt: the main reason for having each backend accessed by one dedicated process is a result of a combination of more than one program needing access to the same data with concurrent access to files not being well supported across different file systems. Before the external arbiter KMail itself needed to be the arbiter, meaning all programs, e.g. Calendar, needing access to "KMail's data" needed to go through KMail. Depending on whether KMail is always running or not, this lead to situation when KMail would suddenly appear "out of nowhere" because it was needed as an access arbiter or functionality provider. The developers thought that it would be better to separate the UI so that it would only be needed when the users themselves interacted with their email, but of course that is a matter of debate, some users might prefer to have their mail UI lauched even when they do not need it right now. It is understandable that a misinterpretation at such a fundamental level will lead to wrong conclusions, for example that deactivating semantic desktop would somehow also deactivate email handling capabilities. The only affected email related functionality of such a disablement is the loss of email search. Mail receiving, reading and composing functionalities do not require search and remain unaffected. Of course basing email search on semantic search would not be necessarily required either, the assumption at the time of decision making was based on the common sense principle that softare specialized in something (in this case search) would yield better results than an attempt of implementing it by developers with experience elsewhere. Common sense, it seems, does not always work out :-) |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!