On 12/06/07, John O'Hara <[EMAIL PROTECTED]> wrote:
This is just one of those bullets that we have to bite on.
AMQP is "getting there", seeing what the low level API shapes out as is part
of the stabalising process.
Top down design / bottom up design -- need both at the same time in my
experience.
true... my only concern is from the IP point of view... the Qpid
project is, rightly, open to those who have not signed the necessary
IP legal agreements to contribute to AMQP... thus could any work that
is done as Qpid actually be contributed to AMQP? Would it create
problems for those of us who wear both hats?
Others who are better versed in the IP issues than me should probably
comment here!
Cheers,
Rob
On 12/06/07, Robert Greig <[EMAIL PROTECTED]> wrote:
>
> On 12/06/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> Completely agree with all of the above.
>
> The discussion of an AMQP API has come up several times in the past
> and I think given how much the protocol has evolved/is likely to
> evolve it is still too early to focus on attempting to create some
> kind of standard API.
>
> RG
>
