Question on C++ broker main program

[Steve Huston <sh...@riverace.com>]

I've been working on the C++ broker/client port to Windows. At this
point, I'm working on the broker and have a question on how the
authors would like me to handle something.

Right now, the broker is arranged as a main program (qpidd.cpp) that
links with a shared library (libqpidbroker, and common). The main
program is in cpp/src/qpidd.cpp and the libqpidbroker code is
primarily in cpp/src/qpid/broker

The qpidd.cpp program has a significant chunk of posix-specific code
that has to change for Windows. In particular, options processing and
daemon usage. I was thinking to do this:

- Split the posix-specific code out to qpidd_posix.cpp, and make a
qpidd_windows.cpp with the Windows-specific pieces.

- The split may be helped by something like qpidd.h so the different
platforms implement the same class/API.

At this point, I'm wondering if the qpidd.cpp and related files should
go down into cpp/src/qpid/broker, or if you want to keep them in
cpp/src still. Any thoughts?

Thanks,
-Steve

Re: Question on C++ broker main program

[Aidan Skinner <ai...@apache.org>]

On Thu, Aug 14, 2008 at 1:03 PM, Steve Huston <sh...@riverace.com> wrote:

> Let me see how far I can get today. If the broker won't go, I'll just
> update the client patch in the jira issue.

Cool, that works for me. :) M4 isn't too far off IIRC.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

RE: Question on C++ broker main program

[Steve Huston <sh...@riverace.com>]

> Andrew Stitcher wrote:
> > On Wed, 2008-08-13 at 23:20 +0100, Aidan Skinner wrote:
> >> On Wed, Aug 13, 2008 at 11:10 PM, Steve Huston 
> <sh...@riverace.com> wrote:
> >>
> >>>> How's this looking for M3? I was going to roll the Beta
tomorrow,
> >>> but
> >>>> could hang off until Saturday (Friday I won't have the
necessary
> >>> bits
> >>>> of internet as I shall be at a Live Musical Event).
> >>> I need to implement something for asynch connect in the broker
and
> >>> give it some testing. If you could wait to Saturday, that would
be
> >>> great.
> >> Can do, I don't really want to wait much beyond that though as
I'm
> >> aiming to roll an RC the week after and I'd like the Beta to get
at
> >> least a full week of testing before that.
> > 
> > This timeline is pushing it for me. I won't be able to have 
> a look at
> > the patches/commit them until Thursday next week it they 
> aren't ready
> > until Saturday as I'm on vacation then.
> 
> I think we really need to get any patch for M3 ready today and
accept 
> that anything that can't make it in this timeframe will be part of
M4.

Ok, I understand.

> If it makes things simpler, perhaps we could focus on a 
> working windows client for M3 and get the broker ported for M4?

Let me see how far I can get today. If the broker won't go, I'll just
update the client patch in the jira issue.

Thanks,
-Steve

Re: Question on C++ broker main program

[Gordon Sim <gs...@redhat.com>]

Andrew Stitcher wrote:
> On Wed, 2008-08-13 at 23:20 +0100, Aidan Skinner wrote:
>> On Wed, Aug 13, 2008 at 11:10 PM, Steve Huston <sh...@riverace.com> wrote:
>>
>>>> How's this looking for M3? I was going to roll the Beta tomorrow,
>>> but
>>>> could hang off until Saturday (Friday I won't have the necessary
>>> bits
>>>> of internet as I shall be at a Live Musical Event).
>>> I need to implement something for asynch connect in the broker and
>>> give it some testing. If you could wait to Saturday, that would be
>>> great.
>> Can do, I don't really want to wait much beyond that though as I'm
>> aiming to roll an RC the week after and I'd like the Beta to get at
>> least a full week of testing before that.
> 
> This timeline is pushing it for me. I won't be able to have a look at
> the patches/commit them until Thursday next week it they aren't ready
> until Saturday as I'm on vacation then.

I think we really need to get any patch for M3 ready today and accept 
that anything that can't make it in this timeframe will be part of M4.

If it makes things simpler, perhaps we could focus on a working windows 
client for M3 and get the broker ported for M4?

Re: Question on C++ broker main program

[Andrew Stitcher <as...@redhat.com>]

On Wed, 2008-08-13 at 23:20 +0100, Aidan Skinner wrote:
> On Wed, Aug 13, 2008 at 11:10 PM, Steve Huston <sh...@riverace.com> wrote:
> 
> >> How's this looking for M3? I was going to roll the Beta tomorrow,
> > but
> >> could hang off until Saturday (Friday I won't have the necessary
> > bits
> >> of internet as I shall be at a Live Musical Event).
> >
> > I need to implement something for asynch connect in the broker and
> > give it some testing. If you could wait to Saturday, that would be
> > great.
> 
> Can do, I don't really want to wait much beyond that though as I'm
> aiming to roll an RC the week after and I'd like the Beta to get at
> least a full week of testing before that.

This timeline is pushing it for me. I won't be able to have a look at
the patches/commit them until Thursday next week it they aren't ready
until Saturday as I'm on vacation then.

Andrew

Re: Question on C++ broker main program

[Aidan Skinner <ai...@apache.org>]

On Wed, Aug 13, 2008 at 11:10 PM, Steve Huston <sh...@riverace.com> wrote:

>> How's this looking for M3? I was going to roll the Beta tomorrow,
> but
>> could hang off until Saturday (Friday I won't have the necessary
> bits
>> of internet as I shall be at a Live Musical Event).
>
> I need to implement something for asynch connect in the broker and
> give it some testing. If you could wait to Saturday, that would be
> great.

Can do, I don't really want to wait much beyond that though as I'm
aiming to roll an RC the week after and I'd like the Beta to get at
least a full week of testing before that.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

RE: Question on C++ broker main program

[Steve Huston <sh...@riverace.com>]

Hi Aidan,

> > I think for M3 a windows specific alternative to qpidd.cpp 
> sounds good
> > enough to me. It can get fancier for M4...
> 
> How's this looking for M3? I was going to roll the Beta tomorrow,
but
> could hang off until Saturday (Friday I won't have the necessary
bits
> of internet as I shall be at a Live Musical Event).

I need to implement something for asynch connect in the broker and
give it some testing. If you could wait to Saturday, that would be
great.

Thank you,
-Steve

Re: Question on C++ broker main program

[Aidan Skinner <ai...@apache.org>]

On Tue, Aug 12, 2008 at 9:36 PM, Gordon Sim <gs...@redhat.com> wrote:

> I think for M3 a windows specific alternative to qpidd.cpp sounds good
> enough to me. It can get fancier for M4...

How's this looking for M3? I was going to roll the Beta tomorrow, but
could hang off until Saturday (Friday I won't have the necessary bits
of internet as I shall be at a Live Musical Event).

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Re: Question on C++ broker main program

[Gordon Sim <gs...@redhat.com>]

Alan Conway wrote:
> On Tue, 2008-08-12 at 12:09 -0400, Steve Huston wrote:
>> The idea of a daemon is posix-ish, so it's not (I think) planned to do
>> a Daemon for Windows. It may have other stuff added that makes no
>> sense for Linux, such as the ability to run as a Windows service.
> 
> I was thinking of windows service as the windows version of daemon mode.
> Multiple qpidd mainlines is one way to go, but if you can come up with a
> sys::BackgroundService interface that could map to both, that would be
> nicer.

I think for M3 a windows specific alternative to qpidd.cpp sounds good 
enough to me. It can get fancier for M4...

RE: Question on C++ broker main program

[Alan Conway <ac...@redhat.com>]

On Tue, 2008-08-12 at 12:09 -0400, Steve Huston wrote:
> Hi Alan,
> 
> > > > Right now, the broker is arranged as a main program 
> > (qpidd.cpp) that
> > > > links with a shared library (libqpidbroker, and common). The
> main
> > > > program is in cpp/src/qpidd.cpp and the libqpidbroker code is
> > > > primarily in cpp/src/qpid/broker
> > > > 
> > > > The qpidd.cpp program has a significant chunk of 
> > posix-specific code
> > > > that has to change for Windows. In particular, options 
> > processing and
> > > > daemon usage. I was thinking to do this:
> > > > 
> > > > - Split the posix-specific code out to qpidd_posix.cpp, and make
> a
> > > > qpidd_windows.cpp with the Windows-specific pieces.
> > > > 
> > > > - The split may be helped by something like qpidd.h so 
> > the different
> > > > platforms implement the same class/API.
> > > > 
> > > > At this point, I'm wondering if the qpidd.cpp and related 
> > files should
> > > > go down into cpp/src/qpid/broker, or if you want to keep them in
> > > > cpp/src still. Any thoughts?
> > > 
> > > The rule for file placement as it stands is currently that 
> > files follow
> > > their namespace. So given that qpidd.cpp really contains 
> > main() which
> > > can't be in any namespace it should be in cpp/src.
> > > 
> > > I think the correct solution to this problem is to figure out the
> > > correct platform dependent/platform independent code split 
> > and make the
> > > platform code appropriate facitilities in qpp/qpid/sys. 
> > However in the
> > > meantime splitting qpidd.cpp and leaving the resultant 
> > files in cpp/src
> > > would be fine until we figure out the best final resting 
> > places for the
> > > code.
> > > 
> > > My opinion only, Gordon or Alan might have different ideas.
> > 
> > Steve, I thought boost::program_options was portable to Windows, am
> I
> > wrong?
> 
> No, that's correct.
> 
> > The options themselves may be different on different 
> > platforms at
> > some point, so perhaps we should separate out the QpidOptions 
> > class and split its implementation.
> 
> Yes, that's what I meant. Similar to the logging options (where syslog
> makes no sense on Windows), some options are platform-specific.
> 

Good point. I'd say extract the platform specific options to new classes
sys::QpidPlatformOptions & sys::LogPlatformOptions class, with
implementations for each platform. The main QpidOptions or log::Options
object can include the platform options as a subgroup. Or something like
that.

> > The Daemon class is already under broker, and could move to sys.
> > 
> > What else is posix specific in qpidd.cpp?
> 
> The idea of a daemon is posix-ish, so it's not (I think) planned to do
> a Daemon for Windows. It may have other stuff added that makes no
> sense for Linux, such as the ability to run as a Windows service.

I was thinking of windows service as the windows version of daemon mode.
Multiple qpidd mainlines is one way to go, but if you can come up with a
sys::BackgroundService interface that could map to both, that would be
nicer.

Cheers,
Alan.

RE: Question on C++ broker main program

[Steve Huston <sh...@riverace.com>]

Hi Alan,

> > > Right now, the broker is arranged as a main program 
> (qpidd.cpp) that
> > > links with a shared library (libqpidbroker, and common). The
main
> > > program is in cpp/src/qpidd.cpp and the libqpidbroker code is
> > > primarily in cpp/src/qpid/broker
> > > 
> > > The qpidd.cpp program has a significant chunk of 
> posix-specific code
> > > that has to change for Windows. In particular, options 
> processing and
> > > daemon usage. I was thinking to do this:
> > > 
> > > - Split the posix-specific code out to qpidd_posix.cpp, and make
a
> > > qpidd_windows.cpp with the Windows-specific pieces.
> > > 
> > > - The split may be helped by something like qpidd.h so 
> the different
> > > platforms implement the same class/API.
> > > 
> > > At this point, I'm wondering if the qpidd.cpp and related 
> files should
> > > go down into cpp/src/qpid/broker, or if you want to keep them in
> > > cpp/src still. Any thoughts?
> > 
> > The rule for file placement as it stands is currently that 
> files follow
> > their namespace. So given that qpidd.cpp really contains 
> main() which
> > can't be in any namespace it should be in cpp/src.
> > 
> > I think the correct solution to this problem is to figure out the
> > correct platform dependent/platform independent code split 
> and make the
> > platform code appropriate facitilities in qpp/qpid/sys. 
> However in the
> > meantime splitting qpidd.cpp and leaving the resultant 
> files in cpp/src
> > would be fine until we figure out the best final resting 
> places for the
> > code.
> > 
> > My opinion only, Gordon or Alan might have different ideas.
> 
> Steve, I thought boost::program_options was portable to Windows, am
I
> wrong?

No, that's correct.

> The options themselves may be different on different 
> platforms at
> some point, so perhaps we should separate out the QpidOptions 
> class and split its implementation.

Yes, that's what I meant. Similar to the logging options (where syslog
makes no sense on Windows), some options are platform-specific.

> The Daemon class is already under broker, and could move to sys.
> 
> What else is posix specific in qpidd.cpp?

The idea of a daemon is posix-ish, so it's not (I think) planned to do
a Daemon for Windows. It may have other stuff added that makes no
sense for Linux, such as the ability to run as a Windows service.

-Steve

Re: Question on C++ broker main program

[Alan Conway <ac...@redhat.com>]

On Mon, 2008-08-11 at 11:45 +0100, Andrew Stitcher wrote:
> On Fri, 2008-08-08 at 14:15 -0400, Steve Huston wrote:
> > I've been working on the C++ broker/client port to Windows. At this
> > point, I'm working on the broker and have a question on how the
> > authors would like me to handle something.
> > 
> > Right now, the broker is arranged as a main program (qpidd.cpp) that
> > links with a shared library (libqpidbroker, and common). The main
> > program is in cpp/src/qpidd.cpp and the libqpidbroker code is
> > primarily in cpp/src/qpid/broker
> > 
> > The qpidd.cpp program has a significant chunk of posix-specific code
> > that has to change for Windows. In particular, options processing and
> > daemon usage. I was thinking to do this:
> > 
> > - Split the posix-specific code out to qpidd_posix.cpp, and make a
> > qpidd_windows.cpp with the Windows-specific pieces.
> > 
> > - The split may be helped by something like qpidd.h so the different
> > platforms implement the same class/API.
> > 
> > At this point, I'm wondering if the qpidd.cpp and related files should
> > go down into cpp/src/qpid/broker, or if you want to keep them in
> > cpp/src still. Any thoughts?
> 
> The rule for file placement as it stands is currently that files follow
> their namespace. So given that qpidd.cpp really contains main() which
> can't be in any namespace it should be in cpp/src.
> 
> I think the correct solution to this problem is to figure out the
> correct platform dependent/platform independent code split and make the
> platform code appropriate facitilities in qpp/qpid/sys. However in the
> meantime splitting qpidd.cpp and leaving the resultant files in cpp/src
> would be fine until we figure out the best final resting places for the
> code.
> 
> My opinion only, Gordon or Alan might have different ideas.

Steve, I thought boost::program_options was portable to Windows, am I
wrong? The options themselves may be different on different platforms at
some point, so perhaps we should separate out the QpidOptions class and
split its implementation.

The Daemon class is already under broker, and could move to sys.

What else is posix specific in qpidd.cpp?

RE: Question on C++ broker main program

[Andrew Stitcher <as...@redhat.com>]

On Tue, 2008-08-12 at 10:03 -0400, Steve Huston wrote:
> ...
> I'll check into that... The Direction enum (at least) will need to
> change since at least one of those values conflicts with a
> Windows-defined macro (hey, don't shoot the messenger ;-)

It's slightly annoying, but I'm not too bothered if you change IN/OUT to
something else. I'd suggest either to change the capitalisation to
None/In/Out/InOut (and put a comment to the effect that Windows chokes
on IN/OUT); or Read/Write/ReadWrite instead; or some better suggestion
if you have one.

Having said that you could just do #undef IN #undef OUT #undef INOUT
after the #include <windows.h> in IocPoller.cpp and in particularly in
any .h file that includes windows.h (I guess Mutex.h and similar should
be the example of this).

Andrew

RE: Question on C++ broker main program

[Steve Huston <sh...@riverace.com>]

> > > What is it that you think is different for windows about 
> the Broker
> > > class?
> > 
> > Only the need to include a different file.
> 
> Umm, I'm not sure that it makes sense to have different Poller
> interfaces for windows and unix. Different implementations, but not
> different interfaces.

Right.

> Although you windows Poller doesn't use the identical 
> interface it does
> appear to be a subset so couldn't it use the same Poller.h as 
> the other
> ports and just not use every constant or implement every unused
member
> function.

I'll check into that... The Direction enum (at least) will need to
change since at least one of those values conflicts with a
Windows-defined macro (hey, don't shoot the messenger ;-)

-Steve

RE: Question on C++ broker main program

[Andrew Stitcher <as...@redhat.com>]

On Tue, 2008-08-12 at 08:02 -0400, Steve Huston wrote:
> ...
> > What is it that you think is different for windows about the Broker
> > class?
> 
> Only the need to include a different file.

Umm, I'm not sure that it makes sense to have different Poller
interfaces for windows and unix. Different implementations, but not
different interfaces.

Although you windows Poller doesn't use the identical interface it does
appear to be a subset so couldn't it use the same Poller.h as the other
ports and just not use every constant or implement every unused member
function.

Andrew

RE: Question on C++ broker main program

[Steve Huston <sh...@riverace.com>]

Hi Andrew,

> > One more code-org-type item in the way of broker being done... The
> > cpp/src/qpid/broker/Broker.cpp file's only (I believe) 
> diffs needed to
> > go to Windows are that constructor (for the Poller creation),
run(),
> > and shutdown() methods - if I could split those methods out to
> > platform-specific files and leave the rest in 
> broker/Broker.cpp, that
> > would get Windows going and let the bulk of the Broker 
> implementation
> > (quite a bit of important functionality) stay as-is now. In the
> > future, there may be some management stuff that may be better
split
> > off, but for now this can get things going. What do you think
about
> > splitting off the implementation of these few small methods?
> 
> I may be missing something, but there isn't anything platform
specific
> about them. The Poller creation, run and shutdown are platform
> independent.

Right, but the Windows code has a different Poller, and needs to
include a different Poller.h file. It's mainly the need to include a
different file that is the difference here.

> What is it that you think is different for windows about the Broker
> class?

Only the need to include a different file.

-Steve

RE: Question on C++ broker main program

[Andrew Stitcher <as...@redhat.com>]

On Mon, 2008-08-11 at 19:58 -0400, Steve Huston wrote:
> Ok, I'll do that...
> 
> One more code-org-type item in the way of broker being done... The
> cpp/src/qpid/broker/Broker.cpp file's only (I believe) diffs needed to
> go to Windows are that constructor (for the Poller creation), run(),
> and shutdown() methods - if I could split those methods out to
> platform-specific files and leave the rest in broker/Broker.cpp, that
> would get Windows going and let the bulk of the Broker implementation
> (quite a bit of important functionality) stay as-is now. In the
> future, there may be some management stuff that may be better split
> off, but for now this can get things going. What do you think about
> splitting off the implementation of these few small methods?

I may be missing something, but there isn't anything platform specific
about them. The Poller creation, run and shutdown are platform
independent.

What is it that you think is different for windows about the Broker
class?

A

RE: Question on C++ broker main program

[Steve Huston <sh...@riverace.com>]

Ok, I'll do that...

One more code-org-type item in the way of broker being done... The
cpp/src/qpid/broker/Broker.cpp file's only (I believe) diffs needed to
go to Windows are that constructor (for the Poller creation), run(),
and shutdown() methods - if I could split those methods out to
platform-specific files and leave the rest in broker/Broker.cpp, that
would get Windows going and let the bulk of the Broker implementation
(quite a bit of important functionality) stay as-is now. In the
future, there may be some management stuff that may be better split
off, but for now this can get things going. What do you think about
splitting off the implementation of these few small methods?

Thanks,
-Steve

> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com] 
> Sent: Monday, August 11, 2008 6:51 AM
> To: qpid-dev@incubator.apache.org
> Cc: Steve Huston
> Subject: Re: Question on C++ broker main program
> 
> 
> Andrew Stitcher wrote:
> > I think the correct solution to this problem is to figure out the
> > correct platform dependent/platform independent code split 
> and make the
> > platform code appropriate facitilities in qpp/qpid/sys. 
> However in the
> > meantime splitting qpidd.cpp and leaving the resultant 
> files in cpp/src
> > would be fine until we figure out the best final resting 
> places for the
> > code.
> 
> Sounds sensible to me.
> 

Re: Question on C++ broker main program

[Gordon Sim <gs...@redhat.com>]

Andrew Stitcher wrote:
> I think the correct solution to this problem is to figure out the
> correct platform dependent/platform independent code split and make the
> platform code appropriate facitilities in qpp/qpid/sys. However in the
> meantime splitting qpidd.cpp and leaving the resultant files in cpp/src
> would be fine until we figure out the best final resting places for the
> code.

Sounds sensible to me.

Re: Question on C++ broker main program

[Andrew Stitcher <as...@redhat.com>]

On Fri, 2008-08-08 at 14:15 -0400, Steve Huston wrote:
> I've been working on the C++ broker/client port to Windows. At this
> point, I'm working on the broker and have a question on how the
> authors would like me to handle something.
> 
> Right now, the broker is arranged as a main program (qpidd.cpp) that
> links with a shared library (libqpidbroker, and common). The main
> program is in cpp/src/qpidd.cpp and the libqpidbroker code is
> primarily in cpp/src/qpid/broker
> 
> The qpidd.cpp program has a significant chunk of posix-specific code
> that has to change for Windows. In particular, options processing and
> daemon usage. I was thinking to do this:
> 
> - Split the posix-specific code out to qpidd_posix.cpp, and make a
> qpidd_windows.cpp with the Windows-specific pieces.
> 
> - The split may be helped by something like qpidd.h so the different
> platforms implement the same class/API.
> 
> At this point, I'm wondering if the qpidd.cpp and related files should
> go down into cpp/src/qpid/broker, or if you want to keep them in
> cpp/src still. Any thoughts?

The rule for file placement as it stands is currently that files follow
their namespace. So given that qpidd.cpp really contains main() which
can't be in any namespace it should be in cpp/src.

I think the correct solution to this problem is to figure out the
correct platform dependent/platform independent code split and make the
platform code appropriate facitilities in qpp/qpid/sys. However in the
meantime splitting qpidd.cpp and leaving the resultant files in cpp/src
would be fine until we figure out the best final resting places for the
code.

My opinion only, Gordon or Alan might have different ideas.

Andrew