On Thursday 12 April 2012 11.50:18 Thomas Tanghus wrote:
> I don't think that would happen with ownCloud. CalDAV and CardDAV is using
> SabreDAV which is pretty well tested.
And what would SabreDAV transmit if it gets an empty data set?
One possibility would be that it would then transmit a perfectly valid and
robust, but empty CardDAV folder.
Of course I don't know whether that is what happens, nor do I want to say that
ownCloud should not be used -- quite the contrary. But I wanted to point out
that until it has actually been properly debugged and tracked down there is
more than one possibility as to what happened.
And right now it seems people are only too willing to always blame Akonadi for
everything that goes wrong anywhere, so by now it gets is fair share of blame
for its actual issues, and then some.
To base such strong language on such a weak analysis seemed questionable.
Actually, use of that kind of language always seems questionable.
> > But I agree it should work, although when I hear that you're still having
> > Nepomuk issues, I wonder which version you're on, because from the 4.8.1
> > release I have seen dramatic improvements here.
> I use two different IMAP accounts with very little trouble. Again when
> connection to the server is lost the resource doesn't always act in a very
> sensible way, and suddenly sends out a multitude of errors for each
> subfolder before it goes offline.
Odd. That one I haven't seen yet.
Here I have Kontact hooked up to four Kolab servers via disconnected IMAP,
plus Google mail via IMAP. All Kolab accounts hold groupware data (calendar,
address books, tasks) from myself and shared folders from others.
Most things are now working as expected.
The imap agents still occasionally turn themselves offline and don't come back
when an old Kolab server does logrotate and restarts services, and I'd love
for them to finally be able to trigger themselves automatically upon network
status on my laptop.
But besides the occasional restart of the agent once a week or so it all works
as expected and by now also increasingly fast. There are still improvements to
be made, of course, but for the most part it now does what it should.
On the calendar side, the calendars work, but it is very slow in startup and
sometimes when adding events. Kontact then takes 98% CPU for a couple of
minutes. My suspicion however is that this is caused by some flakey data in one
of the calendars, as I have about 40 calendar folders, some of them are filled
with sample or test data, and we often play with experimental setups as part
of the Kolab 3.0 development cycle.
Anyhow, this should actually be profileable and debugable, and thus deliver us
some data as to where the calendars might see some substantial performance
enhancements for heavy users.
That aside, it works more or less as it should.
Same for the address books, although the auto completion still does not seem
to use all of them. But this might also have to do with a Nepomuk database
that has not been rebuilt from scratch for some time now.
Those last points I file under "just didn't have the time yet, not necessarily
the system's fault, or obscure enough issues that noone hit them yet."
And for tasks, I am currently experimenting with Zanshin, which is
increasingly becoming the kind of application I want, and I am very excited to
see the things discussed during the KDE PIM meeting put into practice.
> I'm not saying this is a good situation for the end users, but as a long
> time avid KDEPIM user I can live with it because I realize the need for
> this transition in the long term if KDE is to have a reliable and
> extensible PIM solution.
Indeed. There is still work to be done, and I'd love to find ways to resolve
the remaining issues as soon as we can. But KDE PIM is already a lot better
than most people give it credit for, and there are exciting things in its near
to mid term future which I am really looking forward to.