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/