You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Jonathan Robie <jo...@redhat.com> on 2009/02/11 16:57:49 UTC
Spring Housecleaning: Client APIs
Now that M4 is out, I think this is a good time to do spring
housecleaning on the client APIs. Some of these APIs have a lot of
legacy stuff that we don't really for users, one language does things
differently from another language for historical reasons, and there's a
general need for cleaning up.
I'm trying to figure out the best way to go about it. I suspect we
should start with just C++ and Python, making them more alike one class
at a time, writing scraps of code to compare. Naming conventions and
other idioms should suit the given language, but beyond that, we should
seek consistency, so that it's straightforward to look at a C++ client
program and translate it to Python, and vice versa.
Once Python is done, translating that to Ruby is straightforward. We'll
have our quarterly argument about whether to create a Java API that is
consistent with the other languages too, but let's postpone that for now.
Does this make sense? Any suggestions on the best way to go about this?
Jonathan
P.S., I think the management console APIs should be part of this as well.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Spring Housecleaning: Client APIs
Posted by Marnie McCormack <ma...@googlemail.com>.
How will this spring clean account for backwards compability ?
I know of at least on C++ user who is stuck because of API changes, keen to
avoid creating any more !!
Answers on a postcard, about how we will do backwards compatibility across
the piece ...
Marnie
On Wed, Feb 11, 2009 at 5:05 PM, Jonathan Robie
<jo...@redhat.com>wrote:
> Rafael Schloming wrote:
>
>> I think comparing code snippets is a good idea. I would be tempted for
>> starters to identify a few key use-cases/tasks rather than going
>> class-by-class right off the bat, e.g. opening a connection, opening a
>> session, publishing a message, subscribing with a listener, synchronous
>> subscription, creating a message, setting/accessing a header, acknowledging
>> a message, etc.
>>
>
> OK, let's start with that.
>
> I do think we'll want to get to the point that we know that the APIs stay
> consistent, and we know the mechanism we use to keep them consistent. But
> the snippets will help us set direction before we do that.
>
> Would it be better to plan out all the changes, then make them in one fell
> swoop, or to gradually approach a consistent API? I'm inclined to prefer the
> first approach .l...
>
> Jonathan
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: Spring Housecleaning: Client APIs
Posted by Jonathan Robie <jo...@redhat.com>.
Rafael Schloming wrote:
> I think comparing code snippets is a good idea. I would be tempted for
> starters to identify a few key use-cases/tasks rather than going
> class-by-class right off the bat, e.g. opening a connection, opening a
> session, publishing a message, subscribing with a listener,
> synchronous subscription, creating a message, setting/accessing a
> header, acknowledging a message, etc.
OK, let's start with that.
I do think we'll want to get to the point that we know that the APIs
stay consistent, and we know the mechanism we use to keep them
consistent. But the snippets will help us set direction before we do that.
Would it be better to plan out all the changes, then make them in one
fell swoop, or to gradually approach a consistent API? I'm inclined to
prefer the first approach .l...
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Spring Housecleaning: Client APIs
Posted by Rafael Schloming <ra...@redhat.com>.
Jonathan Robie wrote:
> Now that M4 is out, I think this is a good time to do spring
> housecleaning on the client APIs. Some of these APIs have a lot of
> legacy stuff that we don't really for users, one language does things
> differently from another language for historical reasons, and there's a
> general need for cleaning up.
>
> I'm trying to figure out the best way to go about it. I suspect we
> should start with just C++ and Python, making them more alike one class
> at a time, writing scraps of code to compare. Naming conventions and
> other idioms should suit the given language, but beyond that, we should
> seek consistency, so that it's straightforward to look at a C++ client
> program and translate it to Python, and vice versa.
>
> Once Python is done, translating that to Ruby is straightforward. We'll
> have our quarterly argument about whether to create a Java API that is
> consistent with the other languages too, but let's postpone that for now.
>
> Does this make sense? Any suggestions on the best way to go about this?
I think comparing code snippets is a good idea. I would be tempted for
starters to identify a few key use-cases/tasks rather than going
class-by-class right off the bat, e.g. opening a connection, opening a
session, publishing a message, subscribing with a listener, synchronous
subscription, creating a message, setting/accessing a header,
acknowledging a message, etc.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org