libQuotient
libQuotient copied to clipboard
quotient-im
Enable generation of full-fledged AS API
Similar to csapi/, application-service/ could be created. The directory is actually already there but only contains definitions borrowed by CS API. This issue is about generating stubs for AS API calls and the remaining definitions.
The most important here is that AS calls are not only from AS to homeserver (this part is basically an extension to already existing CS API calls) but also from homeserver to AS - meaning that instead of BaseJob these stubs will have to use some other engine underneath, implementing an HTTP server (not yet existing in the library). The situation is not helped by the fact that Qt doesn't have an HTTP server class (though it, amusingly, has QWebSocketServer); so as the first step a decision should be made between the following 3 options (just in case: reimplementing an HTTP server in the library is not an option):
1. Wait for Qt to get HTTP server classes
https://blog.qt.io/blog/2019/01/25/introducing-qt-http-server/ describes current proceedings of The Qt Project to this end (see also for https://bugreports.qt.io/browse/QTBUG-60105). Using this directly from qt-labs repo gives a somewhat precarious API, although pretty actively developed (and it might even make it in time for the eventually-coming Qt 6). Pros: it's the "official" effort backed by The Qt Company; the requirements list covers our use cases quite well. Cons: unstable API (now and in foreseeable future); limited functionality as of Feb 2019, unlikely to match that of mainstream HTTP servers (although why would we even need a full-fledged httpd/nginx instance to serve a bunch of REST requests).
2. Use a 3rd party Qt HTTP/REST server implementation
See, e.g., https://github.com/nitroshare/qhttpengine. Pros: a very good chance to find a necessary feature set and relatively stable API right away. Cons: it's tight coupling with a 3rd party dependency; there are no Qt-grade guarantees on future API stability, maintainability, documentation.
3. Provide a (x)CGI interface, expecting an HTTP server to "already be there"
This punts the HTTP server functionality to either application service authors or admins. Pros: one can use whichever HTTP server he prefers: nginx, Apache, IIS :-D - with respective quality, features (think support of newer TLS versions) and documentation; work on such implementation can be started right away. Cons: we can only punt functionality concerned with listening and accepting connections, terminating SSL and (somewhat) parsing HTTP headers but turning these to strongly-typed C++ stuff and routing requests still falls on the library (unlike option 1).
Honestly, (1) seems like the better option to me. When I asked about this in the Matrix room, I wasn't feeling particularly urgent - more asking about roadmap.
As a result, taking the option that might delay this functionality by a bit but will almost certainly have the fewest consequences for stability and maintainability seems pretty clear.
Certainly there no rush here, I believe adding E2EE is more important and it will take quite a bit of time unless I find another talented head and a pair of hands. However, there's also a design question: I started writing the previous comment with the thought that (1) is certainly the way to go but the more I was thinking about it the more it occurred to me that having an embedded HTTP server exposes my project to security issues (let alone additional configuration), and Qt is not really in server-side business so their implementation will by definition be less mature than, say, nginx. And all in all, (3) feels a bit more along the lines of UNIX philosophy.
With that said, if an admin sets up a bunch of bridges the last thing they want to deal with is "special cases". So if there is some established practice of deploying Matrix applications, I would prefer to plug into it over everything else. If it implies having a "detached" HTTP server, then (3) becomes a no-brainer. If "everybody BYO", (1) is likely better.