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

Alex Merry alex.merry at kde.org
Sat Apr 12 10:34:23 UTC 2014



> 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).

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


-----------------------------------------------------------
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/c1603933/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list