On Tue, Nov 20, 2012 at 2:34 PM, Darryl L. Pierce <dpie...@redhat.com>wrote:

> Last week Justin asked me to take a look at the examples for Proton
> across language bindings. What I found are the following:
>
>                                   C  Python  Ruby  Perl
> Mailbox (Raw API)                [ ] [X]     [X]   [ ]
> Send/Receive (Messenger classes) [ ] [X]     [X]   [X]
> Send/Receive (Non-Messenger)     [X] [ ]     [ ]   [ ]
>

We also have a PHP binding and it has some examples also.

What came out of the discussion was that there's a definite lack of
> depth with the examples. The Mailbox demo is a nice, specific example of
> stored messaging. The Send/Receive examples show very simple
> point-to-point messaging.
>
> But what else should be included in examples? The first thing that comes
> to mind is an example demonstrating subscriptions.
>
> Ideas?
>

A couple of random thoughts off the top of my head...

I think the focus for the dynamic language bindings should really be
messenger based examples. I would say it's really not worth having non
messenger examples for the dynamic languages, particularly as those kinds
of examples are much more involved and maintaining duplicate examples
involves some significant maintenance effort. I would rather see a very
well maintained/structured C example for the non messenger stuff. In fact
I'd go so far as to say we shouldn't bother exposing the non messenger APIs
through the bindings at all, with the exception of python for testing
purposes of course. To be clear I'm not opposed to exposing them, I just
don't think there is any demand at this point and I think it just creates
unnecessary work until there is.

In terms of depth, I'm concerned that deep examples will be
difficult/impossible to maintain well in 5 different languages (6 if we do
something with C++). What I'd suggest we start with is a basic, well
thought out, but simple messenger based example geared towards getting
people started, and strive to keep that consistent and up to date across
all the bindings. I'd keep deep scenarios to one language only (at least at
first), choosing whichever seems most appropriate for that particular deep
scenario.

--Rafael

Reply via email to