[Development] Feedback on Qt RESTful client development

[drwho]

FoxMQ is a layer 7 protocol supporting publish / subscribe, query / 
response and broadcast messaging.  It is currently being implemented 
from a specifcation <https://gitlab.com/craftsmanshipsoftware/foxmq>.

  * messages are made of a header, topic and content.
  * clients can _subscribe_ to a published topic or do a one time fetch.
  * the server manages the subscriptions.  When a publish happens, the
    server determines which clients should receive the topic based on
    who has subscribed to it.
  * clients can send a _change request_ to the server for a specific
    topic.  The client sends new content in the change request.  The
    server then publishes the new content from the client.
  * the server can publish topics independent of client change requests.
  * published topics contain the id of the client that made the change
    request in the message header.  If the server originated the publish
    without a change request, the server's id is used in the header. 
    The purpose of this is to know who made the change request.
  * The header contains a publish count.  Each time the server publishes
    a topic, the publish count increases by one.
  * change requests are sent with the latest publish count for that
    topic.  If two or more clients send change requests for the same
    topic at the same time, the server can choose use the first change
    request it gets with the up-to-date publish count, and then publish
    and increment the publish count.  The server can choose to throw
    away the remaining change requests with the old publish count.  The
    purpose of this is so that server can differentiate between old and
    new change requests using the value of the publish count.
  * clients can also _query_ a topic from the server and the server then
    only responds to that one client with the response. (like http get) 
    This is separate from publish / subscribe functions.
  * FoxMQ specifies two libraries for Qt apps, a client and a server
    library.
  * FoxMQ uses both QSslSockets and QWebSockets in the server. The Qt
    client library only has QSslSockets specified.  Webpages /
    javascript can connect to the QWebSockets.
  * the server can operate either or both of the QSslSocket listener and
    QWebSocket listener on ports of its choosing.
  * server and client authentication can be done using QSslSocket's api
  * supports user access control.  Clients are granted _permitted
    topics_ as they connect or authenticate.  Permitted topics can be
    updated throughout the connection.  (more topics can be permitted
    after authentication for example).  Granting a topic = "user" also
    allows that client to use topics = "user.add", "user.remove",
    "user.ro.list" (user.*).  Granting a topic = "user.ro" would only
    allow that client to access "user.ro.list" (user.ro.*)
  * in a similar way to the UAC, a client can subscribe to a family of
    topics.  Subscribing to "user" also will enable receiving topics on
    "user.added", "user.removed", "user.ro.list".  This behavior is like
    doing ls user*  .  One could also subscribe to user.r and then just
    receive "user.removed", "user.ro.list"

Jon

On 2023-05-12 04:04, Juha Vuolle wrote:
> Hi,
>
> I'm collecting thoughts on how to make developing Qt REST /client/
> applications a smoother experience.
>
> Here I'm thinking about a "typical" client application that wants to
> talk with "typical" REST servers
> as they exist today. As it stands today, the main options are
> XMLHttpRequest on QML side and QtNetwork
> classes on the C++ side (with per-application QML binding option).
>
> REST  is a large and ~loosely defined umbrella and I'd appreciate your
> thoughts - what would actually /help/?
>
> In particular I'm interested in hearing about:
> 1) Current use cases and the bottlenecks/painpoints with them
> 2) Specifically about the seen utility of introducing a fetch() API,
> see below  *)
> 3) Specifically about the seen utility for OpenAPI code-generation
> (below), see below *)
>
> If any thoughts, leave a comment here or here:
> https://bugreports.qt.io/browse/QTBUG-112276
>
> Thank you
> Juha
>
> *) Few of the more promising directions I've looked into are:
>
> 1) Adding fetch() support in QML. Fetch is a Promise based Javascript
> API (https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)
>     The reason I've picked it up is that it's a widely known JS API
> which makes for quite compact and readable code.
>     But - would you find this useful?
>
>     To give an idea, fetching a JSON:
>     fetch("urlhere")
>           .then((response) => response.json())
>           .then((json) => myModel.model = json)
>           .catch((error) => console.log("Oh no", error)
>
> 2) Providing support for OpenAPI code generation tools;  with OpenAPI
> you can generate Qt client networking boilerplate code based on an API
> description (https://openapi-generator.tech/)
>      This would probably build on top of the existing cpp-qt-client
> generator and add things like out-of-the-box QML support and build
> system integration.
>      The concept is well-known and sound, but do you see use for this?
>
> 3) Improving Qt OAuth2 supporthttps://bugreports.qt.io/browse/QTBUG-113218
>
> 4) Possibly: Convenience classes for dealing with tasks around offline
> operation, caching, and also possibly convenience data models.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230512/71c57794/attachment.htm>