Ok, asynchronous data reading is not a problem a well as QIODevice has asynchronous API.
But what about other QFile methods? I mean copy, rename, link and setPermissions. Should they be asynchronous too? Next question - what about QVFSDir? Should directory parsing be asynchronous? 25.09.2011, в 21:51, Georg Rudoy написал(а): > 2011/9/25 Thiago Macieira <[email protected]>: >> On Sunday, 25 de September de 2011 01:48:33 Иван Комиссаров wrote: >>> As long as QFileEngines are marked as deprecated, Qt will have no >>> possibility to implement virtual filesystem. >>> >>> So i would like to discuss features of new VFS. >>> >>> I have 2 questions. First - should it work using QFile and QDir classes as >>> front-end or it should provide its own API like QVFSFile? Second - if we >>> provide new API, should it be synchronous (like QFile) or asynchronous >>> (like Q*Socket)? >> >> I would prefer a new API, more suited for the task. Whether it is synchronous >> or asynchronous, it's up to the implementation. > > Personally, I think QIODevice-derived thing would be just enough, > maybe with additional protocol-specific methods/properties for things > like FTP mode changes, or such. > >> Experience in KDE shows asynchronous is better when a non-negligible delay is >> expected. > > Agreed. Synchronous QFile-style approach just doesn't scale well to > operations with remote sources (thus with much greater latencies and > more faulty ones) and even with local sources that require a lot of > work to be done (think of accessing a file inside a .xz archive). > > After all, it's much easier to make a sync API out of async one given > all the waitFor*-functions than the reverse. > > -- > Georg Rudoy > LeechCraft — http://leechcraft.org _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
