D24887: WIP slave command behavior assertion system

Harald Sitter noreply at phabricator.kde.org
Fri Oct 25 10:48:14 BST 2019


sitter added a comment.


  About the list of unexpected signals in forCommand():
  
  It looks that at least http, ftp, and sftp do call connected() as part of various commands. e.g. all do it during get(). Does that make sense?
  connected() refers to openConnection() in its documentation, and openConnection() says the slave is operating in connection-oriented mode when called, so if openConnection() puts it into connection-oriented mode then not having had a call to openConnection() means it shouldn't be operating in connection-oriented mode. I have no additional understanding besides what the documentation tells me and so it would seem to me that connected() shouldn't be called anywhere but openConnection(). At the same time the documentation for openConnection() does have the neat qualifier forced `     * Opens the connection (forced)`
  
  So I guess my questions are :
  
  - what does connection-oriented mean exactly?
  - what exactly is a forced connection open?
  - how is a forced open different from a casual open?
  - should connected() really be called all over the place?
  - if so, does the client software actually need to do something based on the signal or is it simply a case of "it does no harm, so emitting it unconditionally is easier than not"?
  
  Based on our specific requirements here the expectation class needs some rejiggering to differentiate state violations (e.g. openConnection() neither calling connected() nor error()) from unexpected updates (connected() during get()) from useless updates (listEntry() during stat()).

REPOSITORY
  R241 KIO

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

To: sitter, dfaure
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191025/fbc951bb/attachment.html>


More information about the Kde-frameworks-devel mailing list