qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: Naming etc (was Re: C++ directory re-organization)
Date Tue, 06 Mar 2007 10:37:15 GMT
The major issue is not the naming but the struture.  I agree that we should
have some API which is common across the different languages which probably
maps pretty closely to the AMQP protocol iteself (the protocol looking as
much like an API as it is possible for a protocol to do).  However, for Java
at least, we would expect that we would need a separate manual explaining
how to use JMS over AMQP.

I would agree this is something we want by the time we attempt to graduate
from incubator status.  Right now I suggest we look more at the impact that
future versions of AMQP may have on Qpid (in particular, given the changes
that are likley in 0-10/0-11 I think it would be unwise to start solidifying
an API just yet :-) )...

-- Rob
On 06/03/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
>
> I think we should be aiming to be identical in every respect in which
> it is reasonable to do so. That is to say that, if there is not a very
> good reason for the API being different among the clients, then why
> make it different? There may need to be occasional differences to
> cater for the conventions/type systems/other reasons relating to the
> implementing technology. I'd like to see identical package/namespace
> names (relative to a root), class names, method names, method
> arguments, argument types, even the ordering of the arguments in
> method calls, in so far as its possible within the different
> languages. If I were looking at Qpid for the first time, this would
> speak volumes to me about the unified, well integrated product that
> Qpid is. The manual will only need to be written once (with examples
> that easily translate). Are there any compelling reasons not to do
> this?
>
> Also, if its to be done it should be done as early as possible. Before
> there are too many clients coding to the different APIs that will be
> very annoyed at having it refactored under their feet.
>
> Rupert
>
> On 3/6/07, Gordon Sim <gsim@redhat.com> wrote:
> > Robert Godfrey wrote:
> > > Indeed... But java code littered with disambiguating
> > > org.apache.qpid.amqp.Session and javax.jms.Session sure does look ugly
> :-)
> > > ... now if only you could do aliasing you could call one AMQPSession
> and
> > > one
> > > JMSSession ;-)
> >
> > I agree, it would be nice to be able to define alias type names or
> > 'import as' or something in java. That's one reason that identical
> > naming across several languages may be hard to agree on - each language
> > brings a slightly different set of conventions and constraints into
> play.
> >
> > Getting more consistent doesn't have to mean being identical in every
> > respect though. Perhaps the place to start is at the structural level;
> > deciding whether we want a low level AMQP API for each language,
> > mirroring the protocol structure in effect and therefore more likely to
> > be easily understood across different clients. I would certainly like to
> > make the c++ and python clients more consistent, but haven't thought it
> > all through yet.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message