Review Request 117508: KIO metadata: resume -> range-start, resume_until -> range-end.

[David Faure]

> On April 12, 2014, 10:11 a.m., Alex Merry wrote:
> > Would it not make sense to put the compatibility stuff in KIO::Job::addMetaData, rather than the slaves?  That way it should maintain compatibility on both the application and slave side (for slaves shipped outside KIO).
> > 
> > Although I guess setMetaData dn mergeMetaData would need the same compat hacks... would that be too much of a performance/maintenance hit?
> 
> David Faure wrote:
>     Interesting idea, but yeah, this is rather rarely used metadata, so hacking the central method for it makes me uneasy in terms of performance and maintenance (there are 4 methods: set, add, add, and merge).
> 
> Alex Merry wrote:
>     It looks like the only non-core ioslave to implement this is sftp (unless there's one lurking outside kio-extras, formerly kde-runtime, that implements it).  My only concern would be what happens if the app sets the new metadata, and the slave only reads the old metadata.  Would that ever result in corrupted data (eg: [segment1][segment1][segment2] instead of [segment1][segment2]), or would it just result in extra network traffic?
> 
> Alex Merry wrote:
>     Or is it reasonable to assume we can port all ioslaves that exist, so this will never be an issue?

When resuming a download in FileCopyJob, there's some negotiation with the slave (SlaveBase::canResume), so no bug other than extra network traffic.

When an app requests a range directly ... it has to know that the slave supports it.

And yeah, I'm confident we can port all the ioslaves that support it (I'm not surprised that only sftp is left). So all this compat stuff was really just to be on the safe side, but I don't expect it to be ever useful.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117508/#review55490
-----------------------------------------------------------


On April 12, 2014, 9:55 a.m., David Faure wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117508/
> -----------------------------------------------------------
> 
> (Updated April 12, 2014, 9:55 a.m.)
> 
> 
> Review request for KDE Frameworks and Alex Merry.
> 
> 
> Repository: kio
> 
> 
> Description
> -------
> 
> KIO metadata: resume -> range-start, resume_until -> range-end.
> 
> This is much more self-explanatory to people wanting to request a byte range,
> unrelated to anything like resuming an interrupted download.
> 
> 
> Diffs
> -----
> 
>   docs/metadata.txt b2422f9c816f53d5cec9fbdc0e899329cdb26f30 
>   src/core/filecopyjob.cpp 7bce804eb516f882bfc53af207245e847a27ad8d 
>   src/core/scheduler.cpp f9bc1482b2b8e66b5880f5875567cd485a5b4a5c 
>   src/core/slavebase.h 7417c5e798d843641886fbea62f330524fd12481 
>   src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc 
>   src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 
>   src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb 
> 
> Diff: https://git.reviewboard.kde.org/r/117508/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> David Faure
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140412/4afa296a/attachment.html>