You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2007/01/31 22:40:05 UTC
C++ client API
Currently the C++ client API is like this:
Connection myConnection;
myConnection.open(...);
Channel myChannel;
myConnection.openChannel(myChannel);
myChannel.dostuff...
I would like to change it to be like this:
Connection::shared_ptr myConnection = Connection::open(...);
Channel::shared_ptr myChannel = myConnection->open(...channel args);
myChannel->dostuff...
There are two problems with the current approach:
- constructor creates "lame" objects, need an open() call to make them
useful.
- Letting user call constructor directly means we can't change the
implementation class, whereas the second approach allows us to return
anything inheriting from the user-visible class.
The former issue is plaguing me right now, allowing channels and
connections in a created-but-useless state makes it more complicated to
get exception behavior during startup/shutdown right.
Any objections to this change?
Cheers,
Alan.
Re: [Vote] Jira access
Posted by Rafael Schloming <ra...@redhat.com>.
+1
--Rafael
Bhupendra Bhardwaj wrote:
> +1
>
> On 1/31/07, Robert Greig <ro...@gmail.com> wrote:
>>
>> +1
>>
>> RG
>>
>
Re: [Vote] Jira access
Posted by Bhupendra Bhardwaj <bh...@gmail.com>.
+1
On 1/31/07, Robert Greig <ro...@gmail.com> wrote:
>
> +1
>
> RG
>
Re: [Vote] Jira access
Posted by Robert Greig <ro...@gmail.com>.
+1
RG
Re: [Vote] Jira access
Posted by Steve Vinoski <vi...@iona.com>.
+1
On Jan 31, 2007, at 5:00 PM, Carl Trieloff wrote:
>
> Colin Crist has been consistently providing qpid quality feedback
> and use-case, has integrated qpid with other projects and promoting
> the project. To make his life easier and recognize his
> contributions I would like to propose that we grant him wiki access
> to Qpid to be able to directly place use-cases, notes, and
> requirements directly onto the wiki
>
> I will leave the vote open for 72 hours.
>
> Here is my +1
> regards,
> Carl.
Re: [Vote] Jira access
Posted by Alan Conway <ac...@redhat.com>.
+1
On Wed, 2007-01-31 at 17:00 -0500, Carl Trieloff wrote:
> Colin Crist has been consistently providing qpid quality feedback and
> use-case, has integrated qpid with other projects and promoting the
> project. To make his life easier and recognize his contributions I would
> like to propose that we grant him wiki access to Qpid to be able to
> directly place use-cases, notes, and requirements directly onto the wiki
>
> I will leave the vote open for 72 hours.
>
> Here is my +1
> regards,
> Carl.
Re: [Vote] Jira access
Posted by Andrew Stitcher <as...@redhat.com>.
+1
On Wed, 2007-01-31 at 17:00 -0500, Carl Trieloff wrote:
> Colin Crist has been consistently providing qpid quality feedback and
> use-case, has integrated qpid with other projects and promoting the
> project. To make his life easier and recognize his contributions I would
> like to propose that we grant him wiki access to Qpid to be able to
> directly place use-cases, notes, and requirements directly onto the wiki
>
> I will leave the vote open for 72 hours.
>
> Here is my +1
> regards,
> Carl.
Re: [Vote] Jira access
Posted by Carl Trieloff <cc...@redhat.com>.
Thanks for picking that up, it is for wiki access as the text states.
Daniel Kulp wrote:
> Carl,
>
> Just to be clear....
>
> The Subject says JIRA access, but the message for the vote is for Wiki access.
> I assume it's a wiki access vote since that's what you are describing in the
> message.
>
> Could you clarify that please?
>
> Dan
>
>
> On Wednesday 31 January 2007 17:00, Carl Trieloff wrote:
>
>> Colin Crist has been consistently providing qpid quality feedback and
>> use-case, has integrated qpid with other projects and promoting the
>> project. To make his life easier and recognize his contributions I would
>> like to propose that we grant him wiki access to Qpid to be able to
>> directly place use-cases, notes, and requirements directly onto the wiki
>>
>> I will leave the vote open for 72 hours.
>>
>> Here is my +1
>> regards,
>> Carl.
>>
>
>
>
>
Re: [Vote] Jira access
Posted by Daniel Kulp <da...@iona.com>.
Carl,
Just to be clear....
The Subject says JIRA access, but the message for the vote is for Wiki access.
I assume it's a wiki access vote since that's what you are describing in the
message.
Could you clarify that please?
Dan
On Wednesday 31 January 2007 17:00, Carl Trieloff wrote:
> Colin Crist has been consistently providing qpid quality feedback and
> use-case, has integrated qpid with other projects and promoting the
> project. To make his life easier and recognize his contributions I would
> like to propose that we grant him wiki access to Qpid to be able to
> directly place use-cases, notes, and requirements directly onto the wiki
>
> I will leave the vote open for 72 hours.
>
> Here is my +1
> regards,
> Carl.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: [Vote] Jira access
Posted by Marnie McCormack <ma...@googlemail.com>.
+1
On 2/1/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Carl Trieloff wrote:
> >
> > Colin Crist has been consistently providing qpid quality feedback and
> > use-case, has integrated qpid with other projects and promoting the
> > project. To make his life easier and recognize his contributions I would
> > like to propose that we grant him wiki access to Qpid to be able to
> > directly place use-cases, notes, and requirements directly onto the
> wiki
>
> +1
>
Re: [Vote] Jira access
Posted by Gordon Sim <gs...@redhat.com>.
Carl Trieloff wrote:
>
> Colin Crist has been consistently providing qpid quality feedback and
> use-case, has integrated qpid with other projects and promoting the
> project. To make his life easier and recognize his contributions I would
> like to propose that we grant him wiki access to Qpid to be able to
> directly place use-cases, notes, and requirements directly onto the wiki
+1
Re: [Vote] Jira access
Posted by Kim van der Riet <ki...@redhat.com>.
+1
Kim
On Wed, 2007-01-31 at 17:00 -0500, Carl Trieloff wrote:
> Colin Crist has been consistently providing qpid quality feedback and
> use-case, has integrated qpid with other projects and promoting the
> project. To make his life easier and recognize his contributions I would
> like to propose that we grant him wiki access to Qpid to be able to
> directly place use-cases, notes, and requirements directly onto the wiki
>
> I will leave the vote open for 72 hours.
>
> Here is my +1
> regards,
> Carl.
[Vote] Jira access
Posted by Carl Trieloff <cc...@redhat.com>.
Colin Crist has been consistently providing qpid quality feedback and
use-case, has integrated qpid with other projects and promoting the
project. To make his life easier and recognize his contributions I would
like to propose that we grant him wiki access to Qpid to be able to
directly place use-cases, notes, and requirements directly onto the wiki
I will leave the vote open for 72 hours.
Here is my +1
regards,
Carl.
Re: C++ client API
Posted by Carl Trieloff <cc...@redhat.com>.
Yes, I would go ahead and change it, no concern. I assume constructor
will be moved private.
One nit. I would have expected
Connection::shared_ptr myConnection = Connection::open(...);
Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
myChannel->dostuff...
Alan Conway wrote:
> Currently the C++ client API is like this:
>
> Connection myConnection;
> myConnection.open(...);
> Channel myChannel;
> myConnection.openChannel(myChannel);
> myChannel.dostuff...
>
> I would like to change it to be like this:
>
> Connection::shared_ptr myConnection = Connection::open(...);
> Channel::shared_ptr myChannel = myConnection->open(...channel args);
> myChannel->dostuff...
>
> There are two problems with the current approach:
> - constructor creates "lame" objects, need an open() call to make them
> useful.
> - Letting user call constructor directly means we can't change the
> implementation class, whereas the second approach allows us to return
> anything inheriting from the user-visible class.
>
> The former issue is plaguing me right now, allowing channels and
> connections in a created-but-useless state makes it more complicated to
> get exception behavior during startup/shutdown right.
>
> Any objections to this change?
>
> Cheers,
> Alan.
>
>