Other than noting that things sometimes turn out better the second time around...
On 12/06/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
Ok, I understand that. I was meaning an AMQP API and not a Qpid one. Its doesn't make sense to me to have to write all of the client code twice, when it could be done once. On 12/06/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > Rupert, > > while we in Qpid may wish to start having ideas on an API... the AMQP > group has indicated it as a goal to have such an API deifned by AMQP. > > I don't think we should expend too much effort in that direction > purely as Qpid. Further, there will likely be more changes after 0-10 > (although hopefully of a smaller magnitude), before we get to AMQP > 1-0. > > I suggest that while we may start thinking about an AMQP API right > now, we do not try to prematurely standardize. > > My suggestion remains that we use (in the Java version at least) an > "AMQP"-style API internally; and that early adopters *may* wish to use > this API but must do so with the knowledge that its is likely to > undergo change which may not have backwards compatability. > > From an interoperability point of view; the other important area we > must cover is to have the other Qpid clients easily able to produce > messages that are understood in JMS. For instance being able to > easily send "text", "stream" or "map" messages. This will need to be > standardized for AMQP - but for the moment at least having > interoperability at this level between the AMQP clients would be nice. > > -- Rob > > On 12/06/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > John, > > > > If this is to be the agreed way forward, I think it makes sense to > start > > defining that API as soon as possible. Rather than begining coding for > the > > 0.10 spec in an ad-hoc way; I think it is worth investing a little bit > of > > time in deciding up-front the shape of that API prior to coding. > > > > Personally, I'm +1 for this idea. > > > > Rupert > > > > On 12/06/07, John O'Hara <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > I'm going to bet that your average development shop is willing to > > > > sacrifice a little bit of performance of feature access in order > to > > > > gain the ability to choose between messaging vendors. APIs are > what > > > > usually lock in an application to a specific vendor. If the > > > > application uses an abstract API, vendor lock in can potentially > be > > > > avoided. > > > > > > > > > > 100% true. Which is why most applications have their own shim layer > too > > > :-) > > > In some ways, WCF and BizTalk are Microsoft's shims. > > > > > > Perhaps we're at concensus here: > > > > > > 1) Do non-Java API's for Qpid that is not constrained by the JMS > > > legacy. In > > > all liklihood, the same shape of API will be available for Java too, > just > > > for completeness, in addition to JMS support. > > > > > > 2) Build a WCF driver for Qpid, atop 1) > > > > > > 3) Those who are interested can map NMS to 1) also. > > > > > > Now we just need to decide the shape of that lower level API. > > > There is a lot of talk in the AMQP camp about doing a standard shape > API. > > > We already have some candidates in the wild from iMatix, Apache, and > > > Rabbit, > > > and there have been side discussions about having a beauty contest > or > > > doing > > > pick'n'mix. > > > > > > The API needs to look good and feel right. I get terrified when I > think > > > of > > > the last thing that tried to standardise an API shape across > languages -- > > > DOM. I'm sure we can have something nicer looking than that ;-) > > > > > > Comments? > > > John > > > > > >
