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.
