[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: D28909: smb: port to Result system to force serialization of error/finish condition
From: David Faure <noreply () phabricator ! kde ! org>
Date: 2020-04-25 12:41:09
Message-ID: 8d7979464fd65bca9ded791f65e4b4cd () localhost ! localdomain
[Download RAW message or body]
[Attachment #2 (text/plain)]
dfaure added inline comments.
INLINE COMMENTS
> sitter wrote in kio_smb.h:96
> Sure, if you think it's solid enough from an API POV.
>
> I was thinking that we should amend the slavebase API for KF6 in general. Instead \
> of having error/finished/opened all functions on an API level should return a \
> Result and the slave loop would emit the relevant signal based on the Result. IOW: \
> what currently happens in the derived SlaveBases actually ought to be KIO-internal. \
> That would then also allow us to get rid of the two-class split again. And the \
> "fronting" class is actually a much bigger concern than Result to me. The call \
> finalization logic is 100% code copy and so very easy to get wrong (e.g. sftp's \
> special() not finishing when in fact it should).
Excellent idea, but why wait for KF6?
We could implement a subclass of SlaveBase, in KIO, let's call it SlaveBaseV2, which
- Reimplements all the virtual methods from SlaveBase, in a private section
- Defines a new of virtual methods, called differently somehow
- Implements the signal emission based on the return value of those new virtual \
methods.
This allows for incremental porting of the slaves, instead of a big KF6 breakage.
And the V2 class can be developed in a single slave first, before having to freeze \
its API.
REPOSITORY
R320 KIO Extras
REVISION DETAIL
https://phabricator.kde.org/D28909
To: sitter, dfaure
Cc: meven, kde-frameworks-devel, kfm-devel, azyx, nikolaik, pberestov, iasensio, \
aprcela, fprice, LeGast00n, cblack, fbampaloukas, alexde, Codezela, feverfew, \
michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, \
rdieter, mikesomov
[Attachment #3 (text/html)]
<table><tr><td style="">dfaure added inline comments.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: \
right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: \
#F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: \
inline-block; border: 1px solid rgba(71,87,120,.2);" \
href="https://phabricator.kde.org/D28909">View Revision</a></tr></table><br \
/><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div \
style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; \
background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 \
1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; \
overflow: hidden;"><a style="float: right; text-decoration: none;" \
href="https://phabricator.kde.org/D28909#inline-165370">View Inline</a><span \
style="color: #4b4d51; font-weight: bold;">sitter</span> wrote in <span style="color: \
#4b4d51; font-weight: bold;">kio_smb.h:96</span></div> <div style="margin: 8px 0; \
padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">Sure, if you \
think it's solid enough from an API POV.</p>
<p style="padding: 0; margin: 8px;">I was thinking that we should amend the slavebase \
API for KF6 in general. Instead of having error/finished/opened all functions on an \
API level should return a Result and the slave loop would emit the relevant signal \
based on the Result. IOW: what currently happens in the derived SlaveBases actually \
ought to be KIO-internal.</p>
<p style="padding: 0; margin: 8px;">That would then also allow us to get rid of the \
two-class split again. And the "fronting" class is actually a much bigger \
concern than Result to me. The call finalization logic is 100% code copy and so very \
easy to get wrong (e.g. sftp's special() not finishing when in fact it \
should).</p></div></div> <div style="margin: 8px 0; padding: 0 12px;"><p \
style="padding: 0; margin: 8px;">Excellent idea, but why wait for KF6?</p>
<p style="padding: 0; margin: 8px;">We could implement a subclass of SlaveBase, in \
KIO, let's call it SlaveBaseV2, which</p>
<ul class="remarkup-list">
<li class="remarkup-list-item">Reimplements all the virtual methods from SlaveBase, \
in a private section</li> <li class="remarkup-list-item">Defines a new of virtual \
methods, called differently somehow</li> <li class="remarkup-list-item">Implements \
the signal emission based on the return value of those new virtual methods.</li> \
</ul>
<p style="padding: 0; margin: 8px;">This allows for incremental porting of the \
slaves, instead of a big KF6 breakage.<br /> And the V2 class can be developed in a \
single slave first, before having to freeze its \
API.</p></div></div></div></div></div><br \
/><div><strong>REPOSITORY</strong><div><div>R320 KIO Extras</div></div></div><br \
/><div><strong>REVISION DETAIL</strong><div><a \
href="https://phabricator.kde.org/D28909">https://phabricator.kde.org/D28909</a></div></div><br \
/><div><strong>To: </strong>sitter, dfaure<br /><strong>Cc: </strong>meven, \
kde-frameworks-devel, kfm-devel, azyx, nikolaik, pberestov, iasensio, aprcela, \
fprice, LeGast00n, cblack, fbampaloukas, alexde, Codezela, feverfew, michaelh, \
spoorun, navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, rdieter, \
mikesomov<br /></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic