QtCS2021 - Plugin-based I/O
- Shawn Rutledge (email@example.com)
- 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
- 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
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/