Why using Nepomuk as a contact store is probably not a good idea

[George Goldberg]

2011/7/21 Martin Klapetek <martin.klapetek at gmail.com>:
> 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