Re: [Development] Feedback on Qt RESTful client development

2023-05-12 Thread drwho 


FoxMQ is a layer 7 protocol supporting publish / subscribe, query / 
response and broadcast messaging.  It is currently being implemented 
from a specifcation .


 * 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.

[Development] Feedback on Qt RESTful client development

2023-05-12 Thread Juha Vuolle 
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 support https://bugreports.qt.io/browse/QTBUG-113218

4) Possibly: Convenience classes for dealing with tasks around offline
operation, caching, and also possibly convenience data models.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development