Actually, the Kafka community is really open and actively promotes all open-source clients. :) --> https://cwiki.apache.org/confluence/display/KAFKA/Clients
On Fri, Feb 5, 2021 at 2:53 PM Michael André Pearce <michael.andre.pea...@icloud.com.invalid> wrote: > > > You can actually send management messages in via NMS/JMS, so again not so > sure we need to be maintaining two clients here. > > I would expect if something to do some extra bits, via management address, > to make some kind of management client, that a wrapper over the NMS could > be done there. > > Again an i re-iterate, i would encourage contribution to extend the NMS > client where needed here, not divergence. > > On a separate note, re just adding docs pointing to your project, which is > a not an ASF sister project, I think we want to be careful going down that > route too much, as an Apache project it gets us into some murky waters, i > don't think we need or want to go down. > > e.g. we then open ourselves to having to accept every request to link to a > client project, to keep things fair, and then further what about propriety > clients, that would end up in a very odd position, im not sure where we > even stand, with an Apache ASF project essentially promoting a NON open > source tool, should someone then insist we promote theirs too. > > If you look at Kafka eco system, it provides very few clients, but in > actual fact it is well known there are clients in nearly all languages, > many/most actually developed outside the Apache Kafka project, and even in > some cases for the same language there are a couple of clients on offer. > But the Apache Kafka project does not list or promote those. > > Best > M > > > > > > > > > > > On 5 February 2021 at 10:44, Havret <h4v...@gmail.com> wrote: > > Hi Mike, thanks for the feedback, > > I totally get it. My main inspiration in this regard was RabbitMQ .NET > Client, which of course works on AMQP 0.9.1 and (AMQP 1.0), but actually > uses a proprietary protocol build on top of the mentioned (the same as > ActiveMQ Artemis). Theoretically one could use NMS to talk to RabbitMQ but > nobody does that. At least in the .NET world. This library is not to > replace NMS.AMQP, it just to give the devs a simpler alternative. It is > something between AmqpNetLite which is too low level and NMS.AMQP which is > too overengineered (and constrained with many JMS-specific requirements), > has a really high learning curve and requires additional tooling (spring > container) just to start using it. > > I asked my initial question because I was looking for ActiveMQ Artemis > counterpart of this page https://www.rabbitmq.com/devtools.html I didn't > find one, so I asked. > > On Fri, Feb 5, 2021 at 10:37 AM Michael André Pearce > <michael.andre.pea...@icloud.com.invalid> wrote: > > My points on this is two parts: > > > 1) This only works for Artemis if this was the case, i would have expected > > an "Artemis" specific client to work on the CORE protocol level. > > 2) The point of NMS is its an API, and actually the NMS AMQP client has > > tested compatibility with ActiveMQ Classic, ActiveMQ Artemis, Solace, and > > because its agnostic should work with any other AMQP broker, thats working > > like with QPID clients. > > > The main short coming of NMS atm is lack of task async api, and thats been > > acknowledged, but this is being added with the NMS 2.0 work, thats in > > progress as you know thats in PR. > > > Obviously there's nothing stopping you continuing to maintain the client > > externally as its own project. > > > For these reasons im personally not keen on supporting this/bringing this > > under the Apache ActiveMQ sub banner, i dont have the time, id rather if > > people feel something is missing in existing solutions, that they > > contribute there. > > > > On 4 February 2021 at 20:38, Havret <h4v...@gmail.com> wrote: > > > Hi Justin, > > > You made an excellent point. I will try to answer as thoroughly as I can. > > > AmqpNetLite is a .NET implementation of AMQP 1.0 protocol. It gives you > > full control and all the building blocks you may need to communicate using > > AMQP 1.0. Unfortunately, to use it properly, you need to write quite a lot > > of tedious boilerplate code. For instance, in order to create a connection, > > you would need to write sth along these lines: > > > > https://github.com/Havret/dotnet-activemq-artemis-client/blob/0c7a165c77744ff1d0042511e6d5afc44a3e38e2/src/ActiveMQ.Artemis.Client/Builders/ConnectionBuilder.cs#L10-L53 > > > The same rule applies to other resources like producers, consumers, > > sessions, etc. > > > Having all this implemented one would only utilize the most basic features > > of ActiveMQ Artemis. There is however a good chunk of functionalities that > > require subtle knowledge specific to ActiveMQ Artemis implementation built > > on top of this protocol. For example things like scheduled message > > delivery, scheduled delivery delay, message selectors, attaching to > > address/queue based on routing type, fully qualified queue names, just to > > name a few. All these bits are not part of the original protocol and are > > proprietary to this specific implementation. > > > My library packs all these scraps of knowledge into a simple strongly typed > > SDK, that can be used by any developer without the knowledge that to define > > a message selector on your consumer you need to add to FilterSet property > > of Source frame described value apache.org: > > selector-filter:string=0x0000468C00000004L. > > > Besides that, it adds things that are not included in the raw AmqpNetLite > > by design but are pretty useful in real-life situations, like automatic > > recovery. > > > The thing that I personally (and my fellow .NET developers :)) missed the > > most after switching from RabbitMQ to ActiveMQ Artemis is the topology > > management functionality built right into the client. In RabbitMQ .NET > > client, this is a first-class citizen, and there are extremely popular > > frameworks like NServiceBus and MassTransit that make heavy use of it. > > JMS/NMS 2.0 features like durable subscriptions try to compensate for the > > lack of this functionality to some extent, but unfortunately are far too > > limited. So this is the other thing that this library introduces, and that > > was welcomed with great enthusiasm when I showed it to my colleagues. > > > As the lib doesn't implement nms/jms it is much simpler. You don't need a > > spring container, caching connection factories, single connection > > factories, etc, and the knowledge of how to configure and use them. You > > just need to create your producers and consumers and you're ready to go. > > Everything is thread-safe, so you don't need to worry about creating > > explicit memory barriers, etc. > > > I started this library as a playground for experimentations while > > implementing nms-amqp, but in time it evolved into sth else. My current > > goal is to create a simple well-documented library that will make the > > adaptation of ActiveMQ Artemis as simple and non-intrusive as possible. > > > I hope my reply is not too chaotic and answers your question at least to > > some extent. > > > All the best, > > Krzysztof > > > On Thu, Feb 4, 2021 at 3:14 AM Justin Bertram <jbert...@apache.org> wrote: > > > The docs [1] indicate that the client is "a very lightweight wrapper around > > > AmqpNetLite." If that is the case why is it advertised as the "ActiveMQ > > > Artemis Client for .NET"? Couldn't it be used for *any* AMQP 1.0 use-case? > > > How is it different from AmqpNetLite? What specifically does the wrapper > > > provide? > > > > Generally speaking, one of the nice things about implementing standardized > > > protocols in the broker is that anybody can implement clients and those > > > clients exist completely independent of the broker. There are *lots* of > > > clients for STOMP, AMQP, and MQTT written in lots of different languages > > > for all kinds of different platforms. If we cited your client in the > > > documentation then someone could logically ask why we don't also cite > > > client X in the documentation as well. Clients come and go over time and in > > > my opinion it would kind of be a drag to develop and maintain a list of > > > these clients. > > > > > Justin > > > > [1] https://havret.github.io/dotnet-activemq-artemis-client/ > > > > On Wed, Feb 3, 2021 at 3:21 PM Havret <h4v...@gmail.com> wrote: > > > > > Hi Guys, > > > > > > > > I have been working for over a year now on unofficial ActiveMQ Artemis > > > > Client for .NET, and a set of extension libraries that make its > > > integration > > > > with .ASP.NET <http://asp.net/> Core projects as seamless as possible. > > > > Recently I have written an article describing how to use it on my blog. > > > Do > > > > you think there is any space in Artemis docs to include it, so it would > > > be > > > > easier for .NET folks who are thinking about using Artemis to find it? > > > > > > > > I've reached Clebert in the first place, and he suggested sharing this > > > > here. > > > > > > > > I am sending you links so you could check it out: > > > > article: https://havret.io/activemq-artemis-net-core > > > > repository: https://github.com/Havret/dotnet-activemq-artemis-client > > > > extensions: https://github.com/Havret/activemq-artemis-extensions > > > > docs: https://havret.github.io/dotnet-activemq-artemis-client/ > > > > > > > > Thanks, > > > > Krzysztof > > > > > > > > >
