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/ > > > >
