QtCS2021 - Plugin-based I/O

Session Summary

QML and Qt Quick have some ad-hoc QNetworkRequest code for fetching qml files and image files from web servers, but it seems a bit short-sighted that this is not done on top of some abstraction for reading files from various kinds of sources. (PDF files are rendered via Image, with this being one reason: to reuse that code rather that duplicating it. QTextDocument should support network loading too: that way it will become possible to load QML Text from a URL, or in widget apps with QTextBrowser, etc.) Http will not always be enough: the distributed web is an up-and-coming concept, and there have always been other protocols for fetching files and assets. Maybe we want to allow loading remote assets in QtQuick3D too, etc. Currently KIO is nicely extensible, but it's not built-in to Qt, and the architecture that requires a separate process for each operation is not ideal. What should we do about it? Another aspect of this is that we should probably have an I/O API in QML eventually; and it should probably follow good asynchronous design principles, and look familiar to Javascript developers. Hopefully it could be built upon the same I/O layer. Therefore we should design the new abstraction to be suitable for that.

Session Owners

• Shawn Rutledge (shawn.rutledge@qt.io)

Notes

• KF6 has an option not to fork slaves
• first solve the blocking IO problem before worrying about plugins
• stat, ls, etc... not just reading/writing
• Linux has io_uring now
• GIO if at all, not GVfs
• maybe use d-bus API instead of gio lib?
• some Qt APIs are already async; we just need a few more
  • push vs. pull: more data available; signals?
  • QDir listing is not async, for example
  • could return generators / iterators
• don't block the main thread (QFuture or signal)
• get results as they come (signal)
• will be much better with coroutines
  • https://qcoro.dvratil.cz/
  • https://youtu.be/URP22JsL1XM?t=5884
• just make a new KIO frontend API for Qt, reuse the plugins
  • but that would involve code duplication too
  • threading KIO requires a re-design anyway
• job-based API worked out well in practice, many other places than just KIO
  • webkit uses QNAM with different schemes; it's also job-based
• some protocols need UI : e.g. ssl prompts, password prompts
  • signal of course
• http, file and qrc would be in qt by default (and more?)
• when the slave wants something how does it ask? second pass protocol change: make that possible
• gnome/kde interop problem...
• mounting an existing FUSE filesystem
• need a freedesktop standard for sharing credentials over d-bus
• d-bus without a daemon for non-Linux? but there is p2p qdbus

Conclusions

There are a lot of KIO slaves which ought to be reusable.

Therefore, Qt should become a client for those: API is TBD.

Now that coroutines are in C++20, we should (wait until Qt can use C++20 and) do something like Dan Vratil's solution in https://qcoro.dvratil.cz/