D10078: Add separate lib KF5::DBusRunner

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D10078#253982 <https://phabricator.kde.org/D10078#253982>, @davidedmundson wrote:
  
  > > From my prototyping experiments I can tell that the current approach of recommending in API docs to discard-existing-request-if-new-one-arrived-as-we-assume-just-one-client-who-simply-upgraded-to-a-new-request feels incomplete/undecided
  >
  > Not really. It leaves it up to the implementor.  It covers the simple case well, and any advanced case is still do-able quite easily.
  
  
  ? As implementor, I can report you first hand: I want to know whether it makes sense to continue handling a MatchReply or if not. As in: what is the minimum I need to do to correctly and completely serve the requests.
  
  Having an API which has me doing  potentially useless stuff because it does not tell me whether something is useful to do or not, would we not call this a broken API?
  
  > Adding QObjects in context doesn't make sense. If you're processing stuff you won't process the signal.  If you're not processing things then you don't need the signal.
  
  Well, it makes sense once you process things in other threads with event loops due to further async processing, no?

REPOSITORY
  R308 KRunner

BRANCH
  kdbusrunnerlib2

REVISION DETAIL
  https://phabricator.kde.org/D10078

To: kossebau, broulik, davidedmundson
Cc: bruns, michaelh, ngraham, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180426/36f76752/attachment.html>