I'm just saying I don't see how where / how I would find a common API. I'm supportive of this thought if you find a good common API on a prototype.
Anyway, the issue on that thread is not technical at all. On Mon, Mar 30, 2015 at 10:51 AM, Jamie G. <jamie.goody...@gmail.com> wrote: > 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 -- Clebert Suconic http://community.jboss.org/people/clebert.suco...@jboss.com http://clebertsuconic.blogspot.com
