I am still trying to test if new Kontakt can fullfill the needs that were fullfilled by old Kontakt.

I am now testing version 4.10 (on openSUSE 12.3).

We have several directories contaning vCard address files. By incident I looked into one of them and found a file named WARNING_README.txt with content:

Code: Select all

Important Warning!!!

Don't create or copy vCards inside this folder manually, they are managed by the Akonadi framework!

Rather hidden in a place where users do not normaly look for something that calls it self "important".

But what does this mean? "Manually" can point to many things, but on a computer to change something in a directory/file, it allways needs some program, some editor at least. But I am afraid that this means: "any other program then the KDE version a particular user is running.

Can anybody confirm that this is true?
And can any body then confirm that it is thus true that using the same directory as addressbook from a different sessions and/or a different vCard managing program and/or another system (the directory being NFS exported to others systems on the LAN to be used by others) by users that may or may not use KDE or KDE 4.10 is not allowed?

I hope sincerely that I am utterly wrong, because not being able to share our common addressbooks in our LAN would throw us back to the pre-compter days where each one had his own paper adressbook.

This does not seem to be a popular subject

Nobody here that ever shared an vCard addressbook either on the same system, or using NFS between several systems? I am realy flabbergasted that I am the only one.

hcvv wrote:This does not seem to be a popular subject :(

Nobody here that ever shared an vCard addressbook either on the same system, or using NFS between several systems? I am realy flabbergasted that I am the only one.

I think most people are syncing their stuff with "cloud systems" and not directly via nfs or similar.

However, did you ever try your approach? If it does work: fine. If not, look out for different solutions.

vootey wrote:I think most people are syncing their stuff with "cloud systems" and not directly via nfs or similar.

That seems to be a bit overkill when you use it only within a LAN, or even within one system.

vootey wrote:However, did you ever try your approach? If it does work: fine. If not, look out for different solutions.

Well, this of course functions for years with "old" Kaddressbook. This is for the first time that I see that Kaddressbook in fact claims that it is the only boss of that directory (where my userid is fact not even the owner, I have only read/write acces to it through group privileges).

What I try to find out is if I interprete that "Important Warning" correct in that it forbids:
. me to use that addressbook through another addressbook applicatiion;
. others to use that addressbook through either Kaddressbook or another addressbook application.

Remember that Linux is a multi user system and that thus more users, either at the same moment or at different moments in time, can be loged in, using the (addressbook) applications of their choice on an addressbook that is made available to them.

The usage of NFS is not crucial to this, but I added this to show how the above can be extended to multiple systems.

And about the trial. There is warning, but it is not clear what happens when you ignore it. Wiill things go wrong immediatly and obvious, or are you living on happlily and have a loud bang after two monthes?
I would go for a different solution when somebody here states that doing this is no longer possible, but basicaly I would like to go on using KDE-PIM instead of searching for some other PIM application.

I also asked this in the KDE-PIM mailinglist (because it seemed that nobody could answer here) and I got an answer there that I will publish here for those who are interested:

It mainly means that the program handling the directory won't automatically
check for changes.
I.e. if you change on of the files the data known to applications will still
be the same and will be overwritten if any of those applications change the
same contact.

In theory this could be handled very similar to how the maildir handler
manages its directories, i.e. monitor for changes by other programs. Limited
man power has so far not allowed to apply those enchancements to the vcard
directory handler yet.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

Thanks for sharing this..

Also thanks for sharing the answer you got in the mailing list.. This is exactly what I've been trying to do, and because sharing a VCF directory makes perfect sense in both simplicity and powerfulness. I do agree cloud services are overkill when sharing an addressbook among 3 people.. I've tried it already.. I even installed opengroupware, but the thing was that a lot of information was lost because ofr instance I had too many phone numbers in a contact..

What I'm wondering, as some sort of a hack, if there's a way to force an akonadi resource to reload entirely? That way we could trigger this event every day or every X number of hours..

The only thing that works now is just deleting and re-adding the resource, but that's just crazy..

I also thought of looking for other VCF readers for linux, but haven't been able to find one, unfortunately.. Is there any way to script or macro a GUI application such as Kaddressbook?

Most resources have dbus methods, you may want to see if they expose what you need.

Thanks for confirming that I am not the only one having problems with the way of implementation here.

I am afraid that my talking about he use of NFS, that was only to illustrate how we (my wife and I), here in the house use our common data, distracted from the real problem and thus lead to well ment solutions like "the cloud".

The real problem is that the Kontact implementation thinks it is the best solution in the world using addressbooks "and who would ever try to do this otherwise". Like a real vendor lock in.

For me it is rather simple. There is an addressbook available to a group of people. It lies on a desk somewhere in the house. People can use it for reading and also for changing/adding there when need arises. Now this is computerised. And the addressbook is implemented as a directory with so called vCard files. An open standard. Thus every of the users of that addressbook can use what they want as long as it conforms to the standard. Kaddressbook is one such implementation, but not the only one. I am one of the users of the addressbook, but not the only one. What is so special about this?

The new Kaddressbook does not allow you to do this. I tested by changing an address in another way then using the new Kaddressbook used by my own user (that would fit in the expression "manual"). Even after a reboot, new Kaddessbook of my own user does not show the change. That means that it has a copy of the original addressbook somewhere. This is as stupid as it was in the past for one of the users to write down addressses from the central book in the house and then complaning a year later that their copy was not synched with the changes in the central book. I thought that computerizing was a way to avoid those old bad behaviour.

In other words, my idea is that the design is wrong. And when the design is wrong there won't be a way to repair or by-pass this in an elegant way.

Yeah.. The new kaddressbook won't allow that..

They implemented Akonadi which is more powerful, since it's based on databases.. The thing is that when you add a new resource to kaddressbook, all VCF Files are read and the database is populated.. From that point on, all changes are made on the Akonadi database and only after that, changes are made to VCF Files..

The thing is that NEVER EVER would a change in a VCF file be detected by akonadi..

And that is what Kevin from KDE Support said:

"In theory this could be handled very similar to how the maildir handler
manages its directories, i.e. monitor for changes by other programs."

Going back to my post, by "manually" what I meant was: Right now you can erase the addressbook VCard Directory resource and add it again and you'll see the changes made by the other user.. That's what I meant when I asked if there was any way to automate that procedure. To ask akonadi to read again the VCF files through a script or API call or something..

Any Ideas about that? I'm in no way a DEV, that's clear

Jose

I am afraid you are correct. The only thing is to remove the addressbook from Kadressbook and re-add it.
That e.g. should be done from my KDE 4 session immediatly after my wife edited/added/removed an address from her session.
Not very practical (understatement, should she send me a mail saying: "I did it again"?).

It is a complete misconception that when you tell Kaddressbook: "Hey, there is an addressbook over there, please use it" that it then thinks it owns that addressbook excluding all others to use it. Such behaviour never was the case. And when this regression can not be cured, we can not use this implementation.

Like a real vendor lock in.

I would not use such a term, because actually it's just because manpower is low and tasks to do are always a lot, that some features can not be implemented or were left behind. This is such a case. Don't attribute to malice what is just an effect of lack of developers with time on their hands.

Let us not discuss terms, because it is IMHO even worse then a vendor lockin. Once anybody using new Kadressbook uses the vCard directory, everybody else is locked out. Not technicaly, but practicaly.
And the fact that there isn't enough manpower is of course a pity, etc. but as an end-user I simply do not have a working product. A new version of a product should only be released after at least the old functionalty is there and maybe some new features added (you may then decide if you think they are somehing good for you). But the continuity is important even in a mere home environment.

Old Kontakt served us for years. And now. I am realy a bit desperate. My wife is on an old openSUSE 11.4, I did upgrade to 12.2, but did not install new Kontact and installed all Kontact from KDE the 3.5 repo. I know that isl a dead alley. But we can not go forward with this not finished product. It is not only Kaddressbook. In Kmail there are also many features lost. And we depend on them, use them evry day.

No, I am rely a bit depressed

A new version of a product should only be released after at least the old functionalty is there and maybe some new features added (you may then decide if you think they are somehing good for you).

We're getting a bit OT, but I do not agree. FOSS thrives on "release early, release often". It was the developers who pushed for release of KDE PIM in 4.7, even though it was very rough around the edges. If not, it would have not improved at all (and it has considerably improved - I started using the new versions from 4.6 and they were pretty poor).

That said, the number of people working on PIM is quite low. Not all features can get in reasonable time.

To get the ball rolling, you might start by filing a wishlist request on bugs.kde.org. At the very least, this will make sure that these information will not be lost.

einar wrote:We're getting a bit OT, but I do not agree. FOSS thrives on "release early, release often". It was the developers who pushed for release of KDE PIM in 4.7, even though it was very rough around the edges. If not, it would have not improved at all (and it has considerably improved - I started using the new versions from 4.6 and they were pretty poor).

I know and IMHO that is a very weak point of FOSS. How does one think that end-users (e.g. my wife and a few others I lured into using openSUSE) ever will fully cope with FOSS when things chan
gce all the time. Those people (and I am amongst them while working in IT a long time) are upset when two buttons exchance place in their user interface. How do you think they ever will like it to use a basic end-users program suite like KDE-PIM when half of what they use is lost from one day to the other with the "reason": that will may be back in a few years time.

einar wrote:To get the ball rolling, you might start by filing a wishlist request on bugs.kde.org. At the very least, this will make sure that these information will not be lost.

I will try this. But in fact I am not realy behind such a step. It would only promote the things that are a regression to me. And I am apperently trying to draw attention to this, being a bit assertive. But this will not help people using other now lost features (there must be, I can not believe that only the things I use are touched). Those users are not that fluent in using forums and mailing lists. The all important user base we need. They will simply walk away. This software is for end-users and they will walk away and go for something else when it "does not work" anymore.

The basic step on the redesign should have been:
a) what features are in it now;
b) are there features that we will not take over and how do we find out if many people depend on such a feature;
c) build the new product so that it can replace the old one;
d) add new features to the new product, which will have now a new frame to build upon.

I know this is not loved by developers, it is allways more loved to make new things then to reprogram old ones.
When you work for a boss for your daily living, you will do it, but not when you can decide yourself what to do

I can't believe i didn't post it..

I had made a response, but it looks like I only hit PREVIEW..

Anyway, here's what I remember of it..

1. It looks like it would be easy to query the resource for a manual refresh:

> qdbus <identifier> / org.freedesktop.Akonadi.Resource.synchronize
>
> with <identifier> being something like
> org.freedesktop.Akonadi.Resource.akonadi_vcard_resource_2
>
> (the last part depends on the type of resource just copied the first one I saw
> in my output of qdbus)

2. Looks like there's a bug in Kaddressbook. apparently, right-clicking on the resource and hitting Refresh (or Reload, my locale is spanish) should issue that command but right now nothing happens

> > How do I manually trigger the reload of the addressbook for Akonadi to
> > read again the VCF File list? Right clicking on the resource and clicking
> > refresh doesn't do anything.
>
> Hmm, that should have the desired effect.

I'm not at the computer right now and won't be for 4 or 5 weeks, so I can't confirm it. If you confirm this problem and file a bug in bugs.kde.org, please tell me and I will go and vote it up. Maybe einar could vote it up as well?

3. From here, I can see it as easy to implement a bash script run as root that uses inotify to monitor any changes on the directory and when that happens, the bash script triggers a reload of the resource for every user? I could see a case of that not working entirely if user A changes a contact, the directory gets modified but user B is logged off. I think I can work around that by adding such a check and creating some sort of backlog of resource-refresh commands until user logs in.. Will have to be on the computer to check it.

Maybe it's just me, but I'm most used to trying to fix things by hand many times hehe... Sadly, I now realize how I did it for the fun of it, and because I could feel so much control of LINUX. I even //lived// with gentoo for about 5 years!. I fondly remember those times of finding patches for getting Feature X working on a latest ebuild that had been pushed to portage... and creating a local portage repository and all ! That's for IT guys, though... Now that I've moved on and try to juice the last minute of my time as productive time, I've moved on to OS X... I would never move to Windows, though... Just having a simple bash shell in OSX let's me do things that wouldn't even be remotely possible in Windows without installing Cygwin. With that said, I do miss the times of powerfulness of Linux. At my dad's company, for instance, I set up an NX Server to which every user remotely logs-in so we have centralized control of documents, shared addressbooks (with this shortcoming), automated monthly, weekly, daily and hourly backups of documents, access control of documents, centralized printing control and employee stations are cheap-o computers.. Even having windows using virtualbox for some users!.. Try doing that with OSX!

Anyway, will update you on what happens when it happens... Let me know if you file that BUG!