- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
4.4.3 Is Upon Us
|
|
|
Comments (38)
18 earlier comments in the full thread.
Is the problem perhaps that KDE has moved away from the philosophy of doing one simple thing well? You notice that several apps are now trying to integrate with korganizer. You can see why, there are all kinds of things which if you think about it might be desirable to have generate a todo or a deadline. But if the underlying database gets screwed, the damage is really widespread. Lets hope we can carry on using kmail and kjots by themselves, otherwise its going to be off to thunderbird, and one guesses, gjots. Which last is not a bad package anyway.
Quoting: E-mail, calendar, messenger, etcetera. It's not massive concurrent access. But because these applications run for so long, sooner or later you will get collisions and deadlocks.So create separate dbs for email, calendar etc. If there is still concurrent access expected, take a big (interruptible) lock as appropriate which should not be an issue given that a user will normally not go in a click frenzy. I mean if even a plain text mbox file can work for thunderbird, an sqlite DB should be more that enough for kontact.
Quoting:Is the problem perhaps that KDE has moved away from the philosophy of doing one simple thing well?
Akonadi is just meant to do one thing and do it well: Handling and storing your contacts.
In the past, different programs did it all their own way. The idea is to 'separate' the part which handles contacts etc., call it Akonadi, and then all KDE-apps use it for their needs to interface with the contacts-database.
Also, I believe Akonadi was designed for 'large enterprises' as well (though I don't know any large enterprises using KDE4?), hence they thought performance could be an issue.
now I remember why I never ran into issues with kontact, like any other aggregated app like that, it's ugly and in trying to do many things it utterly fails at doing any of them well. Mind you I have found exactly zero similar apps in any OS or DE that doesnt meet that exact same description.
The latest, they are now telling me their address book is not working. I'll probably have to go in tomorrow and move them to icedove/thunderbird over the weekend. There's really no excuse for this. Kmail and the rest of it worked perfectly for years. The only nice thing about this was how easy it was to migrate the korganizer to Sunbird, just point it at the ics file and it was done. It also turns out to print nicely in lists. Not bad at all.
Quoting:So create separate dbs for email, calendar etc.
But if you do that, these applications cannot share contact information anymore. The entire idea behind Akonadi is that all apps can share contact information. Sort of like LDAP on steroids. I like the idea.
Quoting: But if you do that, these applications cannot share contact information anymore.Why so? Most of the searches will be key based so, for example, it will be just fine to search the contact db with information from email db. Maybe their design requires elaborate joins, sub-queries etc. spawning these various components, but in my opinion if their design requires an elaborate DBMS just for desktop usage to work satisfactorily then there is something wrong with the design.
Your design is too complex. In your design, if an application wants to find out about contact information then it would need to search the e-mail app's database, the messager app's database, the calendaring app's database, etcetera. And all this would need to be coded in the app, so it cannot search databases from apps that it does not know about.
Akonadi keeps all contact information in one place. A much better design. The only problem is that they used MySQL as the background database. They could have used SQLite even though it cannot work concurrently. Putting a concurrent front API on a non-concurrent backend is a known and solved problem. Disk device access for one.
Akonadi keeps all contact information in one place. A much better design. The only problem is that they used MySQL as the background database. They could have used SQLite even though it cannot work concurrently. Putting a concurrent front API on a non-concurrent backend is a known and solved problem. Disk device access for one.
Sander -
Shame on you for suggesting that the brilliant minds of the KDE team could possibly fail to learn from solutions that have been implemented over and over and over and over and over and over and over and over and over again.
If they failed to implement something along those lines it must be because old solutions have no place in their zippy new world.
Shame on you for suggesting that the brilliant minds of the KDE team could possibly fail to learn from solutions that have been implemented over and over and over and over and over and over and over and over and over again.
If they failed to implement something along those lines it must be because old solutions have no place in their zippy new world.
Quoting: Your design is too complex. In your design, if an application wants to find out about contact information then it would need to search the e-mail app's database, the messager app's database, the calendaring app's database, etcetera.Not really, don't know the requirements so all I have said is to separate out information into separate dbs where possible, if concurrency is really a problem. Of course, use patterns can dictate keeping some related information in one db. The simple logic being that if concurrency is the problem then it will usually be due to different applications accessing the db concurrently and it would be expected that those would access their own tables in the db. So there should be quite a lot of scope of separation in there. If lots of cross-talk is expected for certain tables, then it will make sense to put those into the same db.
Quoting: Akonadi keeps all contact information in one place."Place" as in db, or "place" as in table, or "place" as in something else? In any case, it still can; I don't understand what's the problem in there. All that I have said of the design is that separation into different dbs can help with concurrency where not much overlap is expected, and related information can still be in one db. I don't think it makes sense to argue more about that since the use patterns are not very clear.
Quoting: The only problem is that they used MySQL as the background database.That's the main problem we are discussing, isn't it? As I said, if they *need* something like MySQL to give them acceptable performance for desktop use then something is wrong with their design.
Quoting: Putting a concurrent front API on a non-concurrent backend is a known and solved problem.Not if they require transactional semantics from backend.
>Not if they require transactional semantics from backend.
Isn't that cute? Note the requirement: "transactional semantics from backend", not "transactional semantics".
So...I suppose that a front-end can't take care of that.
Better call the Rails guys...
Isn't that cute? Note the requirement: "transactional semantics from backend", not "transactional semantics".
So...I suppose that a front-end can't take care of that.
Better call the Rails guys...
Quoting:don't know the requirements
Well, I don't know exactly what a concurrent database means - because I don't know **** about databases (except that MySQL always throws errors on my desktop), but I might help you on that. The Wikipedia piece about Akonadi is probably written by someone from KDE, so I think it sums up the requirements quite well:
-Should be extensible, because 'other' desktop projects might use it as well (usable beyond KDE), -concurrent read, write, and query access. Think it has something to do with their requirements it should be suited for the desktop where a single person is using it, or at a company site where 100 people are querying shared information, -unique desktop wide object identification and retrieval - I think that part tells there should be one 'one-fits-all' database were everything is stored.
Reading over the list Hans posted, I guess that something like CoughDB (which is ACID compliant) may have been a better choice for Akonadi. Especially since IMHO contact information isn't easy to map to an RDBMS.
I'm no database guru so I could be way off-- isn't LDAP expressly designed for this kind of usage? Not so fast for writes, but very fast for reads, and flexible in ways that RDBMs are not. Because they don't have an inflexible table structure, but can add and remove new fields as you need them. For these reasons big heavy-duty directories and user/asset managers like Fedora Directory Server, which used to be Netscape Directory Server, then iPlanet Directory Server, and then SunONE directory server are LDAP-based.
Makes sense, TC.
In fact, it uses 'extended IMAP'. LDAP can't store mails I assume.
MySQL is probably chosen as they wish to use it for 'groupware' servers too.
If you want 'desktop' and 'groupware server' to use the same framework, you end up with 'groupware server capabilities' on the desktop.
http://conference2006.kde.org/conference/talks/9.php
http://conference2006.kde.org/conference/talks/9.php
Understand there may be arguments for what they do. But the bottom line is, right now we are on Sunbird and not going back, and if Kmail blows up, we'll be off that in a flash too. Whatever the desirability of various features, being able to use the thing is the most important. Without that, you don't have a product, or users.
I think my last post touches the core of the problem:
If you make something for the desktop and something else for groupware servers, you might end up with duplicated efforts, if you 'unify' desktop and groupware, you end up with 'groupware' capabilities on a desktop, and the result is the 'dependency' on MySQL.
If you make something for the desktop and something else for groupware servers, you might end up with duplicated efforts, if you 'unify' desktop and groupware, you end up with 'groupware' capabilities on a desktop, and the result is the 'dependency' on MySQL.
Quoting: if you 'unify' desktop and groupware, you end up with 'groupware' capabilities on a desktop, and the result is the 'dependency' on MySQL.Normally apps should be programmed to use something light like sqlite for light/desktop use and separate DB server like MySQL for heavy/server usage. For instance Trac issue tracking system supports multiple DBs, so SQLite can be used for light usage and Postgres/MySQL for heavy usage -- we have used both as per requirements without issues.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post