2011/7/21 Martin Klapetek <[email protected]>: > On Thu, Jul 21, 2011 at 00:30, Paolo Capriotti
<snip> >> Please forgive me if what I say isn't entirely correct, but I believe >> KDE PIM has a custom storage infrastructure for their data (Akonadi) and >> only exports data to Nepomuk for indexing/searching purposes. >> >> That's a perfectly sensible architecture, and it mirrors exactly what I >> am advocating for KDE Telepathy. >> >> As for plasma active, I have no idea. In any case, what they choose to >> use shouldn't affect us. A bad technical decision isn't justifiable with >> an argument about the community. > > Watch out here. You haven't proved it is a /bad/ technical decision, so far > you've only showed us that there are better solutions. I agree there are > more solutions to our problems, some even fits better into our needs. But > yet again, we decided to choose Nepomuk because of the bigger picture here > (I'm getting tired of writing this again and again :P) Essentially, the way I see it is this: You have proposed a valid, and in some respects better design for KDE-Telepathy. However, the current design has many aspects (mentioned by myself, Martin and Ivan in previous mails) which we believe make it advantageous over what you have proposed. In particular, we want to be a part of the deep integration between KDE applications that is taking place at the moment, and that gives extra weight to adopting common technologies rather than doing it our own way. As a result, the use of Nepomuk is *not optional*, even if we don't use it in KDE-Telepathy itself, the data needs to be synced there. This means that adding in folks and writing all the necessary backends to get the same integration is an increase in the amount of code and complexity we need (essentially adding an additional abstraction layer). There is also a second factor at play here: The project has dragged on for years without making a release - we are finally reaching that stage now, and hopefully we can use the momentum of that to keep things moving much faster than they have been in the past. I think it would take a very compelling argument (backed up with tangible evidence) to make us throw out a chunk of our architecture and redesign/rewrite at this stage. The project has been plagued by this kind of architectural angst too many times before (e.g. Decibel->Mission Control shift, the debate over whether Akonadi should be part of this architecture, and of course the decision over using Nepomuk). This is the main reason why I have so little patience with the same old discussions being dredged up time and time again. > > If the real world usage will show us it was a bad decision and that it > doesn't really work, I'm willing to fully acknowledge you were right and we > were idiots. But from my experience so far, it works perfectly fine. Sorry, > but I remain unconvinced. You posed some valid theoretical points, but the > practice speaks different so far... I agree entirely with this sentiment. If it turns out using Nepomuk is a disaster, I'll be very happy to acknowledge that you were right, but currently I still believe (based on the evidence of writing and using the code) that it will not be a disaster. -- George _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
