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