If I'm not mistaken, AMQ and HQ configurations are not all too different - how does this become recursive? A common API is just an adapter layer to everything else, when did abstraction of this form become a performance penalty?
Cheers, Jamie On Mon, Mar 30, 2015 at 12:09 PM, Clebert Suconic <clebert.suco...@gmail.com> wrote: > The behaviour on how things happen at the server will make it hard to > have a common API. > > Second: it gets really recursive. it becomes an extra layer of > abstraction where you need the code as fast as possible. > > > I'm just saying I don't see how someone could make a single API for > the broker. what would be the pluggable points? > > The protocol layer is implemented at the server, storage at the > server... and they all need Asynchronous implementation. I don't see > a single point where you could plug these behaviours. If we had it we > wouldn't need all this discussion. > > > On Mon, Mar 30, 2015 at 10:34 AM, Jamie G. <jamie.goody...@gmail.com> wrote: >> Hi, >> >> Just a quick question on "For instance, when you receive a message, >> activemq is blocking a thread, while it should be asynchronous on the >> server, a callback be sent to the client whenever it was possible, >> from a callback handler.", can you explain this? >> >> Are you referencing synchronized vs actor based/callback code? >> >> How would this impact James' proposal? >> >> Cheers, >> Jamie >> >> On Mon, Mar 30, 2015 at 11:33 AM, Clebert Suconic >> <clebert.suco...@gmail.com> wrote: >>> If there was a semantic behavior in common where this would be >>> possible, we probably wouldn't need any improvements at all. >>> >>> For instance, when you receive a message, activemq is blocking a >>> thread, while it should be asynchronous on the server, a callback be >>> sent to the client whenever it was possible, from a callback handler. >>> >>> >>> It's different how lockings will happen, what makes a common API even >>> more unlikely. >>> >>> >>> >>> >>> Besides, It gets a bit recursive really, implementing an interface to >>> the broker implementing the broker. >>> >>> >>> I'm not saying it's impossible, but it seems unlikely to be possible. >>> >>> On Mon, Mar 30, 2015 at 9:23 AM, James Carman >>> <ja...@carmanconsulting.com> wrote: >>>> All, >>>> >>>> With all the talk over the last week or so regarding the "Broker >>>> Wars", especially after reading Rob Davies' email about how the broker >>>> has been tweaked through the years to emphasize different aspects >>>> (long-term storage for instance), it occurred to me that we might be >>>> able to move past all this craziness by providing an abstraction layer >>>> above the broker and try to make them "pluggable." >>>> >>>> If there really are situations where the broker needs to focus on one >>>> particular aspect of message delivery, that sounds to me like the >>>> "strategy" pattern. If a broker can be written in such a way that it >>>> is allowed to focus on certain aspects and maybe ignore or completely >>>> forego others, then it would seem to me that the code could be made >>>> much more straight-forward, because it doesn't have to try to be the >>>> "swiss army knife", solving everyone's problems at one time. >>>> >>>> Of course, this may be just a pipe dream and there's no way to do it >>>> (admittedly I'm not terribly familiar with the code), but I thought >>>> I'd throw it out there as a possible approach. I mean, we do this >>>> sort of thing already with the persistence providers, so maybe there's >>>> an opportunity here as well. >>>> >>>> Thoughts? >>>> >>>> James >>> >>> >>> >>> -- >>> Clebert Suconic >>> http://community.jboss.org/people/clebert.suco...@jboss.com >>> http://clebertsuconic.blogspot.com > > > > -- > Clebert Suconic > http://community.jboss.org/people/clebert.suco...@jboss.com > http://clebertsuconic.blogspot.com
