Why would examples in every normative language not be appropriate?
Synchronization may be an issue, but wouldn't examples be easily
synchronized with language-specific API updates?


On Wed, Jan 2, 2013 at 12:50 PM, William Henry <whe...@redhat.com> wrote:

> Hi Mary,
>
> It is my understanding that the existing C++ examples should work because
> the proton based C++ API the Qpid proper API with the proton C API under
> the covers.
>
> That said, I'm not sure what testing has been done to make sure this is
> true.
>
> Also it would seem that perhaps there might be two sets of examples (?).
> i.e. What happens to old style addresses in the new proton enabled C++ API?
> Do the still just work? Can I mix simple proton addressing with the more
> complex previous addressing that allowed us to build exchanges and queues?
>
> William
>
> ----- Original Message -----
> > > 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++).
> >
> > Above you mentioned the possibility of C++ examples. Is anyone
> > currently
> > working on creating C++ examples?
> >
> > Thanks,
> > Mary
> >
> > -----Original Message-----
> > From: Darryl L. Pierce [mailto:dpie...@redhat.com]
> > Sent: Friday, November 30, 2012 4:05 PM
> > To: proton@qpid.apache.org
> > Subject: Re: Language example apps...
> >
> > On Fri, Nov 30, 2012 at 12:36:34PM -0500, Rafael Schloming wrote:
> > > 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.
> >
> > Yeah, sorry to forget that.
> >
> > > 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.
> >
> > If we keep the languages as consist as possible across the bindings,
> > then
> > one language doing a deep example and others doing more general
> > examples
> > should be workable. Assuming the one language is as easy to
> > understand for
> > someone not familiar with it to follow.
> >
> > --
> > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> > Delivering value year after year.
> > Red Hat ranks #1 in value among software vendors.
> > http://www.redhat.com/promo/vendor/
> >
> >
> >
> >
>



-- 
Joseph B. Ottinger
http://enigmastation.com
*Memento mori.*

Reply via email to