Hello,

>>If that is the ambition in the longer term, but you’d nevertheless want to 
>>start developing the project as a Qt module, then a repository in the
>>playground/ namespace on our gerrit server can be a good start.

That's actually the status we've left the discussion at from the backlog. Our 
expectation is to integrate the project as Qt module with total Qt governance. 
Though, we would still need maintainance roles assigned to us to make sure we'd 
be able to provide around the clock support as our cross-platform Suite would 
rely heavily on this module for the messaging.

As to the licensing and commercial support, well that's would motivate the 
redesign and implamentation of the project under Qt. We would need you guys to 
confirm that you'd have the ressource model and the benefit to integrate the 
module to the commercial offer. Our product make us of the commercial licensing 
model so no issue on our side.

As to the test tooling  for this project: Apart from the Plumber open source 
project that we use as the (agnosticà CLI tool, all the tooling in-use are 
docker compositions of the respective official MQ platform images and perf 
tools which are available with an open source licensing model. The test tooling 
would be the same as the one used by Qt.

With regards to the developpement guidelines, well that would be easy, our 
developpers are Qt specialist that are familiar with both the public and 
private Qt idoms. Both the proposed designs are compliant with the core 
guidelines, they vary in the way the public API would be exposed:

  *   The bridge design (Abstraction/PIMPL tree) is compatible with Qt PIMPL 
idiom and enforces more type safety using an abstraction tree for API exposure 
instead of polymorphic aggregation like it would normally be the case for the 
RHI approach for example while still proving the unsafe functionallity oriented 
approach through runtime reflexion access (we're using QtProtobuf to generate 
our APIs which MOC-able types).

  *   The functionality oriented design proposal is similar to the RHI 
integration and threats the messaging as a loossly configuratable and 
commanable API where few or none of the platform dependant implementation is 
exposed in the public namespace thus providing an ideal type erasure, this 
we're mostly reluctant about. It works well with the RHI API because the 
runtime is tighthly coupled to the hardware, the user can easily debug the 
runtime by capturing frames and inspecting the graphics commands. using. With a 
distributed system, this would be a much tedious task had the user issued any 
careless wrongfull assumption.


>>If that is the ambition in the longer term, but you’d nevertheless want to 
>>start developing the project as a Qt module, then a repository in the
>>playground/ namespace on our gerrit server can be a good start. As pointed 
>>out on the wiki-page above, the qt-labs/ namespace is a bit special and
>>reserved for employees of The Qt Company.
That sounds good.

>>Does the project’s code live anywhere today where we can have a look? That 
>>would probably be a good start.
Currently, We have 2 design proposals for the cross MQ platform design that we 
can provide you UML diagrams for. We did not decide yet on which to adopt for 
the project, maybe you can help decide which one is better suited for the 
project from a user friendliness and safety point of view ?
As to the backends, we have a standalone private propriatary Qt based Kafka C++ 
code that is just waiting to be integrated in a cross MQ platform design and an 
ongoing AMQPP standalone implementation that bearely started. This is not 
available in a public repo. If you think you'd be ok to move forward with the 
project according to your ressource model for licensing and integration, we'd 
have no issue openning the sources under a Qt GPL licensing model and move 
everything to the playground.

Br
 QtFluentMQ Team




________________________________
From: Volker Hilsheimer <volker.hilshei...@qt.io>
Sent: Wednesday, August 23, 2023 4:57 PM
To: team fluentmq <fluen...@outlook.com>
Cc: development@qt-project.org <development@qt-project.org>
Subject: Re: [Develo pment] QtFluentMQ

Hello QtFluentMQ Team,

The project as you have described it sounds very cool and could be interesting 
for many Qt users building distributed systems. So thanks for the work so far 
and for reaching out!

As for providing a repository on our gerrit server for your project, and 
perhaps moving it under the governance of the Qt project: As per 
https://wiki.qt.io/Requesting_New_Repositories, the repository location depends 
on whether we agree that this project should become part of the Qt 
distribution, and how quickly this could possibly happen. This requires some 
discussion with a few people in the project, and in The Qt Company. E.g. we 
need to see how the licensing works out, and involve the team that would have 
to support commercial license holders when they start using the module and have 
questions, or want to report bugs. Also, the environment required to run the 
auto tests for this project might need to be discussed with our CI team. And by 
moving the project under Qt Project governance, you’d agree to develop this 
project in a way that it meets our compatibility commitments, platform and 
compiler support plans, release processes etc.

If that is the ambition in the longer term, but you’d nevertheless want to 
start developing the project as a Qt module, then a repository in the 
playground/ namespace on our gerrit server can be a good start. As pointed out 
on the wiki-page above, the qt-labs/ namespace is a bit special and reserved 
for employees of The Qt Company.

Does the project’s code live anywhere today where we can have a look? That 
would probably be a good start.

Cheers,
Volker


On 23 Aug 2023, at 14:41, team fluentmq <fluen...@outlook.com> wrote:

Hello,

I forgot to mention that we're looking forward to a qtlab repository creation 
to migrate the Kafka soruces and developpe the AMQP support project as a Qt 
module.

The design proposal is built around the bridge pattern which is a PIMPL tree. 
We have people rooting for a plugin based arch similar to Qt's RHI design.

Both design provide seamless public API from the user point of view. The latter 
is less popular choice in the team due to type safety issues as the dynamic 
configuration capabilities of the module would require to ignore configurations 
and commands if the feature is not supported by a particular (version of a) MQ 
platform. The bridge design offers stronger type safety thanks to the 
abstraction & PIMPL tree pair.

Please feel free to ask if you need more info on the design details if 
necessary for the voting process.

Br
QtFluentMQ Team


________________________________
From: team fluentmq
Sent: Thursday, August 17, 2023 4:36 PM
To: development@qt-project.org <development@qt-project.org>
Subject: QtFluentMQ


The "QtFluentMQ" project aims to create a user-friendly and versatile message 
queue (MQ) client using the Qt 6 framework. This client seamlessly handles 
communication with major MQ platforms. The first release would implement the 
AMQP protocol thus supporting RabbitMQ, ActiveMQ, Apollo, IbmMQ, AmazonMQ and 
more. It will also migrate the existing Kafka implementation to Qt to support 
the Kafka platform as well, the current MQ market leader.

At its core, the project involves a top-layer abstraction called QMQInstance. 
This layer acts as a bridge between the application and various MQ platforms. 
Within this layer, there are two main components: QConsumer and QProducer, 
which can also be referred to as QQmlConsumer and QQmlProducer when working 
with QML.

QMQInstance provides a unified QMessage Interface that simplifies the process 
of sending and receiving data to and from different MQ brokers. This uniform 
interface streamlines the interaction with multiple MQ platforms, making it 
easier for developers to integrate messaging functionality into their 
applications.

One of the standout features of this project is its dynamic configurability. 
The client can be configured through a JSON input, which can either be provided 
in memory or via a stream. This flexibility allows developers to adapt the 
client's behavior to specific use cases and requirements without significant 
code changes.

Additionally, the project supports queues context switching. This means that 
the client can seamlessly switch between different queues or channels within 
the MQ platforms. This feature is particularly useful for managing multiple 
communication channels efficiently and ensuring the smooth flow of data.

Finally, the QtFluentMQ actively supports open-source initiatives like 
Plumber<https://github.com/streamdal/plumber>, a versatile CLI tool for 
seamless interaction with various messaging systems, including Kafka and 
RabbitMQ. By collaborating with projects like Plumber, Fluent MQ enhances the 
CI/CD process by offering an all-in-one tooling package that streamlines 
operations and simplifies integration tasks."

In summary, QtFluentMQ project offers a comprehensive and easy-to-use solution 
for interacting with various MQ platforms. Its abstraction layer, dynamic 
configurability, and support for queues context switching contribute to a 
seamless messaging experience for developers working with Qt 6 applications.


Br
QtFluentMQ Team
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to