On Mon, Sep 10, 2012 at 9:26 AM, Darryl L. Pierce <dpie...@redhat.com>wrote:

> I've been working the past few weeks on providing a stable API layer in
> Ruby on top of the swig bindings. I've made a few decisions in the
> design and want to now float them out here to get feedback.
>
> You can take a look at the WIP in my Github repo [1].
>
> NAMESPACES
> ==========
> The APIs all live within the Qpid::Proton namespace. Each major group of
> APIs exist within namespaces below them. For example, the Driver APIs
> live within Qpid::Proton::Driver, Qpid::Proton::Driver::Connector and
> Qpid::Proton::Driver::Listener.
>
> CLASSES VS MODULE METHODS AND CONSTANTS
> =======================================
> All of the APIs are module-level methods in the design. There's no need
> to instantiate an object to work with them. You only need to pass in the
> object types returned by the underlying Proton C implementation.
>
> Enumerated types are represented by classes that provide a simple,
> consistent interface for working with symbols that have roughly the same
> names as the enum. For example, Qpid::Proton::Trace represents pn_trace_t,
> and values can be accessed using Qpid::Proton::Trace::RAW.
>
> UNIT AND FEATURE TESTING
> ========================
> For now I've focused on writing Rspec tests to cover as many conditions
> as I can setup, with the goal of keeping the coverage at 100% or within
> 2 points. Some of the conditions aren't easy to setup, so those I'm
> documentingn with a note to fix them in future.
>
> For feature tests, I plan to write those using Cucumber. But I'd like to
> start a second conversation there since we can use Cucumber to test
> features across all currently supported languages (Ruby, Python, Perl,
> PHP, Java). Since Cucumber supports these [2] we can write one set of
> feature tests and ensure all implementations and bindings work as
> expected.
>
> Questions? Thoughts?
>

So my general thought is that we should focus on the messenger stuff first
for high level languages like Ruby. The main reason being that the lower
level interfaces might want to get tweaked a bit more for performance
reasons, whereas the messenger interface itself is higher level and
therefore less likely to change. So given that the point of this is that
it's a stable API, that is really the most stable place to start. I also
think in a lot of ways the other stuff is distracting for a language like
python or ruby and not as interesting to those communities.

I took a look at the messenger example and I'm a little surprised not to
see Messenger and Message exposed as objects. Granted the bindings are
procedural because the C API is procedural, but they're pretty much begging
to be exposed as objects. As they are it looks like you still need to do
manual memory management, I would think by mapping the procedures into
methods on Messenger and Message objects and by tying pn_messenger_free and
pn_message_free into the respective destructors, we could make things a
whole lot safer, e.g. avoid dangling pointers and the like that a user
could use to segfault the interpreter.

Regarding cucumber, this is the first I've seen of or heard of it. My
initial reaction could probably be described as mildly skeptical by someone
prone to extreme understatement, but I'll try to keep an open mind and read
up on it sometime soon. ;-)

--Rafael

Reply via email to