Oh, I am not sure what you mean with regard to the date. The text does not contain the date.
On Tue, Jan 11, 2022 at 2:46 PM Steve973 <steve...@gmail.com> wrote: > Since this is my first contribution to one of my all-time favorite > libraries, this is pretty exciting for me. I would be glad to update the > blog post immediately. I will also add the things that we discussed with > regard to how this is a glue component, etc etc. If you need me to change > (or shorten) it, let me know and I can turn that around quickly, as well. > > On Tue, Jan 11, 2022 at 2:06 PM Claus Ibsen <claus.ib...@gmail.com> wrote: > >> On Tue, Jan 11, 2022 at 7:13 PM Steve973 <steve...@gmail.com> wrote: >> > >> > Thank you for the review and comments. I completely agree with you >> that it >> > is cumbersome to require users to create a java object. Your >> suggestion of >> > making the subscription URI-based is good, and I still need to figure >> out >> > how to provide the filter (Predicate) for evaluating exchanges for >> > participant suitability. Do you think that including a Camel bean ID in >> > the url (and a corresponding bean in the registry) for the Predicate >> would >> > be a good approach? >> > >> >> Yes we could allow both kind, eg the user can send the java object and >> have full control from java. >> >> Then in the uri, you can have a filter parameter of type predicate. >> Then in the uri you can refer to a bean with the #bean:myFilter >> syntax. >> If you think that a predicate based on the simple language makes >> sense, then we could also use that via the uri >> >> filter=${body} > 100 >> >> The file component has some option that allows this, but lets fight >> one battle at a time, and just get a #bean:xxx syntax to work first. >> >> >> But before doing all of this, then I think the current PR can be merged >> as is. >> >> Can you update the blog post date to today? >> >> >> >> >> > On Tue, Jan 11, 2022 at 8:04 AM Claus Ibsen <claus.ib...@gmail.com> >> wrote: >> > >> > > On Sat, Jan 8, 2022 at 4:09 PM Steve973 <steve...@gmail.com> wrote: >> > > > >> > > > Hello. I would like to add a little more to this conversation, >> since you >> > > > mentioned my reason for contributing this code. My motivation to >> add >> > > this >> > > > EIP component was because a couple of years ago, I read about the >> dynamic >> > > > router EIP within Camel, and I thought that it would be perfect for >> what >> > > I >> > > > needed to do in my project at work. It looked like my clients could >> > > > register with the dynamic router processor, but further reading of >> the >> > > docs >> > > > and my own use of it revealed that this was not how it was >> implemented. >> > > I >> > > > was not able to use it for my use case, but I had to move on and >> > > implement >> > > > this behavior myself. >> > > > >> > > > Now that I had some time, I thought that I would contribute this >> idea to >> > > > Camel so that others would be able to use this particular type of >> "glue" >> > > > right out of the box that fits use cases that are like others in >> camel, >> > > but >> > > > expanded in certain areas that include, but are probably not >> limited to: >> > > > >> > > > - the content-based router (choice), but the choices are fully >> > > > subscriber-initiated and do not need to be known at compile time >> > > > - the dynamic router (processor in Camel core), and I outlined >> the >> > > > differences in the previous email, so no need to re-hash here >> > > > - the message filter, but instead of creating the filter at >> compile >> > > > time, consumers provide their own filter at runtime >> > > > - the selective consumer, but turned the other way around: >> instead of >> > > > sending messages to (potentially a list of) recipients, and >> letting >> > > them >> > > > all determine which messages to process or discard, this >> component >> > > allows a >> > > > consumer to subscribe with its filter so that the router can >> handle >> > > this >> > > > (centrally) and only send messages to the (first) appropriate >> > > subscriber. >> > > > If we need a recipient list mode, that can easily be added so >> that it >> > > sends >> > > > to all matching recipients. >> > > > - the "To Dynamic" EIP, but the sender does not need to know >> about >> > > > dynamic recipients, and variables do not have to be set >> > > > >> > > >> > > That is a good break-down and perspective >> > > >> > > > I hope this shows how this contribution is not only "glue", but >> that it >> > > is >> > > > useful glue that provides simplified routing for developers that >> have use >> > > > cases that overlap in the list of features above. While you could >> > > achieve >> > > > anything in software by composing a solution of several different >> pieces, >> > > > and implementing the glue that helps them to work together and, in >> this >> > > > case, also implementing the runtime registration of recipients, this >> > > > component ties these things together and makes it simple. It is not >> > > > intended to be its own messaging system, but to facilitate >> messaging to, >> > > > and from, other sources where the decision is truly runtime-based. >> > > Indeed, >> > > > you might have another messaging system that provides filtering, >> etc, but >> > > > this component introduces a new feature to provide this in a way >> that is >> > > > independent of other components/transports, and can, therefore, be >> used >> > > as >> > > > a dynamic integration point between completely different messaging >> > > systems. >> > > > >> > > >> > > Yes I can see the validation, when you accept that it's not a >> > > messaging system with client/server actors. >> > > So when you say that you can subscribe/unsubscribe then it's not on >> > > the same page as it would be with a JMS/Kafka client that subscribes >> > > to a broker system. >> > > >> > > I wonder if you could research if you can make the subscription >> > > simpler, as I think it's a little bit of a "hurdle" that Camel users >> > > would >> > > need to construct a java object to subscribe for basic subscription. >> > > >> > > You could have sub context for the action and channel, so if you just >> > > want to subscribe you can send an empty message to >> > > >> > > dynamic-router:control/subscribe/my-channel?id=123 >> > > >> > > You could also allow to auto-gen uuid for the subscription id, so if >> > > id is omitted then one is returned >> > > >> > > String uid = requestBody(....) >> > > >> > > Anyway that is food for thoughts for improvements. >> > > >> > > What you have sent today as PR - lets review it. I can see its >> > > usefulness and its potential if you continue to work on it. >> > > >> > > >> > > >> > > >> > > > Thanks again, >> > > > Steve >> > > > >> > > > On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <claus.ib...@gmail.com> >> > > wrote: >> > > > >> > > > > Hi Steve >> > > > > >> > > > > We can see from your work that you have put a lot of effort and >> > > > > devotion into this, with an example and blog post as well. >> > > > > >> > > > > However you say that the reason you wanted this was due to the >> dynamic >> > > > > pattern in the EIP book. >> > > > > >> > > > > The issue is that the EIP book is about messaging and integration >> > > > > patterns and that these patterns >> > > > > does not apply to all software projects. >> > > > > >> > > > > The dynamic pattern as in the EIP book is actuall a pattern in >> > > > > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the >> many of >> > > > > them out there. >> > > > > They all offer a way for clients to subscribe and unsubscribe to >> > > > > topics (and or queues) and very often have filtering as well so a >> > > > > client can say they the only want message that matches X criteria. >> > > > > >> > > > > In other words its a domain that is for a messaging system, and >> this >> > > > > gets quickly complex when you have distributed systems, and HA >> with >> > > > > failover, and now also with "the cloud", and even across multiple >> > > > > cloud vendors with hybrid cloud. >> > > > > Your implementation in Camel would be very limited in use-case as >> its >> > > > > a single context / in-memory only "queue". >> > > > > >> > > > > >> > > > > If on the other hand there was a new messaging system (called >> foobar), >> > > > > and it was a well used system, then it would be worthwhile to >> > > > > implement a camel component for such system. >> > > > > In other words Camel is the glue to systems, but its "not a >> "server" >> > > > > system itself". >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <steve...@gmail.com> >> wrote: >> > > > > > >> > > > > > Hello. I have sent a few messages here on this list about an >> > > alternate >> > > > > > Dynamic Router EIP component implementation that I have been >> working >> > > on. >> > > > > > If anyone has some time, I would like to get more community >> input and >> > > > > > opinion on what I have done so far. You can see the ticket >> here: >> > > > > > >> > > > > > https://issues.apache.org/jira/browse/CAMEL-17154 >> > > > > > >> > > > > > It contains a link to the component module on my fork of the >> Camel >> > > repo >> > > > > (in >> > > > > > the comments), and I have included a blog post draft ODT >> attachment >> > > that >> > > > > > introduces this component, why I wanted to implement it, and >> basic >> > > > > > discussion on how to use it. >> > > > > > >> > > > > > If any of you would be kind enough to take a quick glance and >> let me >> > > know >> > > > > > what you think, I would be quite grateful. >> > > > > > >> > > > > > Happy holidays, if you are celebrating. Take care, and be well, >> > > > > regardless. >> > > > > > >> > > > > > Thanks, >> > > > > > Steve >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Claus Ibsen >> > > > > ----------------- >> > > > > http://davsclaus.com @davsclaus >> > > > > Camel in Action 2: https://www.manning.com/ibsen2 >> > > > > >> > > >> > > >> > > >> > > -- >> > > Claus Ibsen >> > > ----------------- >> > > http://davsclaus.com @davsclaus >> > > Camel in Action 2: https://www.manning.com/ibsen2 >> > > >> >> >> >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 >> >