[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]