[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Activity services merge
From:       Ivan ?uki? <ivan.cukic () kde ! org>
Date:       2010-09-27 16:15:44
Message-ID: 4ca0c2e3.887b0e0a.7cd8.3289 () mx ! google ! com
[Download RAW message or body]

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

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]