Activity services merge

[Ivan ?uki?]

*** 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.



Cheerio,
Ivan
 



-- 
Sanity is the trademark of a weak mind.
    -- Mark Harrold