qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: New Ruby bindings...
Date Fri, 03 Jun 2011 11:12:26 GMT
On 05/31/2011 07:57 PM, Darryl L. Pierce wrote:
> On Friday I spoke with Ted Ross for a bit about doing a more Ruby-esque
> set of bindings for the Qpid APIs. The APIs wouldn't be a replacement
> for the ones generated by SWIG, but would instead be a wrapper around
> them that feels more like a Ruby API.
>
> I've done an initial stab at this, creating several new class:
>
> Qpid::Messaging::Connection

What is the purpose of 'attr_accessor :connection_impl' (likewise for 
session_impl etc)?

In convert_options, the c++ client (as of 0.10 release) now supports the 
underscore based variants as synonyms (for uniformity with python).

> Qpid::Messaging::Session

The create_sender() method treats the options as applying to the address:

    # Creates a new endpoint for sending messages.
    def create_sender(address, options = {})
      address = "#{address};{create:always}" if options[:create] == :always
      Qpid::Messaging::Sender.new(@session_impl.createSender(address))
    end

I can see that this is a useful way of dynamically building addresses. 
However to me it would be better to have an address abstraction for 
that, so you would do something like:

   session.create_sender(address("my-topic", "my-subject", {create: 
always}))

Certainly it needs to be clear what address means in the method as is. 
If it had other options in it then the result would likely be an 
unparseable address.

One of the key motivations for the address string approach was to allow 
the same addresses/config to be used in applications of different 
languages. While I fully accept that specific languages may be able to 
offer additional simplifying constructs, we don't want to lose that 
basic uniformity either.

I assume that whatever create_sender does, create_receiver would 
eventually follow.

We should sync up the clients on acknowledge/reject. Python and c++ 
currently don't quite match here and it would be good to reach agreement 
on one approach that we can then move towards in all languages.

> Qpid::Messaging::Sender
> Qpid::Messaging::Receiver

Sender/Receiver don't expose capacity, unsettled and available. The 
send() method doesn't have a sync flag, the fetch() method doesn't have 
a timeout.

There are also no methods for getting the session for a given 
sender/receiver, or the connection for a given session. (Or indeed for 
retrieving existing sessions, sender or receivers by name).

Are these merely issues in completeness or is this intentional 
simplification?

> Qpid::Messaging::Message

I'm not sure amqp/string is needed as a content type. It think an 
existing content type would be better in most cases (e.g. text/plain or 
some other specific binary format if the data is not text). It certainly 
shouldn't be the default as none of the other clients use or recognise 
that as anything special.

> which you can look at in my Github repo[1].
>
> I'd like some feedback on the design so far.

I think it would be worth listing out the specific things that could be 
more Ruby like.

E.g. exposing the options more directly seems like a perfect example of 
the sort of thing that you would want in the exposed API, likewise the 
built in support for content types (both features the python API has for 
example where the c++ is more limited).

My assumption is that other than specific rubyisms we would want to be 
pretty close to the existing python (and less so the C++) API. Hence 
listing those rubyisms explicitly helps focus the debate.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message