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:[email protected]
