On Thiago's input: >>If there's no commercial interest and there are no resources to support such >>an offering, then just don't include it in your commercial offer in the first >>place. >>Admittance into the Qt Project does not and cannot depend on there >>being a commercial value and sufficient employee capacity.
We're not requesting Qt to assess the commercial interest for us. As we explained in the previous mail, we're simply acknowleding Volker's inputs on the need for internal discussions on such matters (mainly commercial support and CI ressources) first before agreeing to include the project in the Qt offer, because there are ressource to acount for on Qt side on this indeed. >>In fact, it would be good for you to have a couple of open source-only >>releases or commercial >>technical previews to assess the interest of your customer base (and ditto for >>any other companies participating in the Qt Project ecosystem). To clarify the context, the API we're proposing is designed to handle the messaging part for which we need an agnostic support for our products to function. The Qt integration proposal was motivated by the fact that the Qt project went through some great evolutions with regards to cloud tech by implementing APIs such MQTT and QtGrpc. So we figured that while at it, we'd help complete the effort by providing this part of the APIs we're currently implementing as it would cause no harm to our products had it been exposed. Doing so would benefit both the Qt community by widening the cloud tech support and us by getting a community feedback on the usage of this module which is one if not the most sensitive part of our product. As to the motivation of implementing the protocols ourselves instead of writing glue code on top of the apache/librdkafka open source C++ client (which was the initial plan), this comes from the fact that after inspecting these, we found out that for the most part, they not only are behind (years behind actually) on schedule with regards to broker specs (even the Java ones, reffer to KIPs for librdkafka for example, there are at least 200 (we stop counting after this) function critical/not acceptable KIPs not mitigated yet in both the Java and C++ clients). Also, since this is basicaly the main(only) I/O nerwotk interface of our clients, it'd be funny if all of a sudden our clients started to experience crashes because we did not care to implement protocols. You might think that contributing instead of reimplementing would be a better idea, but then, those clients are written with different designs (some relying on C, other not, some are poorly written, some are old C++ style), with absolutly no common denominator, it would counter productive and a nightmare to build a seemless support on top of these and if we did, we would loose the robustness guarentees that we'd have acheived as soon as one of the contributor would add some content unless we decide to use a liftetime fork, which would defeat the purpose of using 3rd parties to begin with. >>What should matter is the quality of the code, the commitment of a group of >>developers to develop it for the medium and long term, adherence to Qt Project >>principles of governance. This is why we're actually requesting a playground repo for, ie for Qt to assess both the quality as well as the adherence to the code of conduct. Hopefully, we've been working with Qt and using it's private modules for a long time and would not let the community down on this 🙂 >>And since it will use resources of the CI, which is provided by and paid for >>by the Qt Company, whether that can be supported too. Discussed in the first part. Br QtFluentMQ Team ________________________________ From: team fluentmq <fluen...@outlook.com> Sent: Saturday, August 26, 2023 2:38 AM To: Vladimir Minenko <vladimir.mine...@qt.io> Cc: development@qt-project.org <development@qt-project.org> Subject: Re: [Development] QtFluentMQ Hello, First of all, thanks for being supportive of the project. >>I do not quite understand who exactly you expect to confirm and what you mean >>with "ressource model”. Volker mentioned: >>As for providing a repository on our gerrit server for your project and >>perhaps moving it under the governance of the Qt project [...] This requires >>some discussion with a few people in the project, and in The Qt Company. >>[...] involve the team that would have to support commercial license holders >>..." We understood from that there are some internal discussions to be settled first prior to providing a gerrit server for our project to be moved under the governance of the Qt project. Following your email, I went through Volker's inputs again and noticed this: >> 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. Does this mean that we can create the Qt INFRA task to request the repo creation and merge the relevant parts of our code and complete the AMQP implementations while the discussions are being led ? Are the discussions settlement required for the "moving it under the governance of the Qt project" part of the process only ? Because if that's the case, factoring in the positive feedback we got so far, we'd be ok to open the relevant part of our sources already in the playground repo while you settle on the integration part in which case, We'd say let's Hack On ! Br ________________________________ From: Thiago Macieira Sent: Friday, August 25, 2023 9:07 PM To: development@qt-project.org Subject: Re: [Development] QtFluentMQ On Friday, 25 August 2023 00:17:08 PDT Vladimir Minenko via Development wrote: > Hello team fluentmq, > > > > 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 > > I do not quite understand who exactly you expect to confirm and what you > mean with "ressource model”. If there's no commercial interest and there are no resources to support such an offering, then just don't include it in your commercial offer in the first place. Admittance into the Qt Project does not and cannot depend on there being a commercial value and sufficient employee capacity. In fact, it would be good for you to have a couple of open source-only releases or commercial technical previews to assess the interest of your customer base (and ditto for any other companies participating in the Qt Project ecosystem). What should matter is the quality of the code, the commitment of a group of developers to develop it for the medium and long term, adherence to Qt Project principles of governance. And since it will use resources of the CI, which is provided by and paid for by the Qt Company, whether that can be supported too. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ________________________________ From: Vladimir Minenko <vladimir.mine...@qt.io> Sent: Friday, August 25, 2023 9:17 AM To: team fluentmq <fluen...@outlook.com> Cc: development@qt-project.org <development@qt-project.org> Subject: Re: [Development] QtFluentMQ Hello team fluentmq, > 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 I do not quite understand who exactly you expect to confirm and what you mean with "ressource model”. Despite that, I also think the idea is cool and can bring new values for Qt when done. I think Volker outlined the next steps in his reply. Greetings! -- Vladimir Minenko vladimir.mine...@qt.io +49 171 90 61 461 Senior Product Manager, Qt Foundations, mobile and desktop platforms The Qt Company - https://qt.io On 23. Aug 2023, at 18:27, team fluentmq <fluen...@outlook.com> wrote: 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<mailto:volker.hilshei...@qt.io>> Sent: Wednesday, August 23, 2023 4:57 PM To: team fluentmq <fluen...@outlook.com<mailto:fluen...@outlook.com>> Cc: development@qt-project.org<mailto:development@qt-project.org> <development@qt-project.org<mailto: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<mailto: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<mailto:development@qt-project.org> <development@qt-project.org<mailto: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<mailto:Development@qt-project.org> https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org<mailto: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
