Hi, On Sun, Sep 25, 2011 at 3:18 AM, Иван Комиссаров <[email protected]> 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)? >
What exactly is the use case for having VFS at the QFile and QDir level? I would prefer QFile and QDir to always operate on the actual file system and have nothing to do with virtual file systems. The current implementation of file engines is quite flawed - it has a malloc cost for every QFile/QDir (i think this is fixed in 4.8 by using the QFileSystemEngine) and more importantly it injects special handling for certain files throughout the application. This most often breaks application code. As an example, if you implemented a tar file engine which makes .tar files appear as directories, it changes the behavior of your file dialogs (you can step into tar files now). It also breaks all the file iteration code because .tar files don't appear as files anymore. I haven't thought this through but I would like to see a QNAM style API for virtual file systems (with iteratation support etc). And just like one has to add explicit network support (and not expect some magic QFile/QDir handling), one has to add explicit vfs support in the code and expose API like QWebPage::setNetworkAccessManager. Girish _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
