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 <[email protected]> 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:[email protected]] > > Sent: Friday, November 30, 2012 4:05 PM > > To: [email protected] > > 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 > > <[email protected]>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.*
