[Nepomuk] Activity services merge

[Sebastian Trueg]

> *** This is a cross-list-thread ***
>
>
> Hi all,
>
> I'm in the process of recreating the activity-related services and I'd
> like to merge the kded activities daemon and
> nepomuk activities service.
>
> Essentially, the current state is this:
>  - kded activities daemon handles the data needed by workspaces (plasma,
> kwin) which can exist even without nepomuk,
> while when nepomuk is online, it acts like cache
>  - nepomuk service which links resources (documents, apps...) to
> activities.
> Both will experience significant changes, mostly feature-wise.
>
> The reasons for the proposed merger into one service:
>  - easier maintainability
>  - less code duplication (both services need to know the list of
> activities, names etc.)
>  - less d-bus communication (kded daemon needs to pass most things to the
> nepomuk service)
>
> Reasons why it was separated in the first place
>  - kwin people didn't want to depend on nepomuk
> A: The merged service would continue to work w/o nepomuk running so, apart
> from the fact that the service will have to
> be linked against libnepomuk, nothing will change
>
> - kded module was kept as simple as possible to avoid crashing kded
> A: See below
>
> - nepomuk tracking of opened/closed/etc. documents should not depend on
> existence of activities
> A: This can be kept as well, it is only that both activities and tracking
> will live in one executable, which would be the case
> even w/o the merge
>
> - plasma people didn't complain about anything except of missing features
> in kded daemon whilch will be addressed
> anyway :)
>
>
> So, from my POV, the only remaining problem is crashing the kded if
> everything is put inside it. For this, there are two
> possible solutions:
> 1) Make an out-of-process kded module
> 2) Make an independent d-bus service which will start as soon as anybody
> tries to access some of its method (my
> favourite feature of d-bus)
>
>
> Thoughts? Complaints?
>
> If not, the merger will happen.
>
> Any ideas regarding the name of the service would be more than welcome.
> IIRC, Trueg had something against
> ActivityManager. For me, the alternative could be UsageTracker... but
> using "Tracker" in the name wouldn't be a good
> idea.

I am totally fine with a merger. My only problem is the kded stability. So
as long as that is addressed I fully agree that one service makes more
sense.

Cheers,
Sebastian