[boost] Boost.Application new version available.

Subject: [boost] Boost.Application new version available.
From: Re (re.tf_at_[hidden])
Date: 2013-11-14 20:32:27

 Hi Brook,

Thanks for your commenets.

I will try aswer your questions, if any thing is not clear, let me know.

First at all, this lib is a working in progress (prototype), and it is open
for suggestions and improvements. 

Feel free to suggest a new feature or change, I'm trying to listen to
everyone. And I have tried to implement all the requests that come to me so
far. (Obviously, this is limited to my knowledge (which is not big))

>> I am having trouble seeing how it would integrate with Boost.Asio.

Well, I use Asio only to support signals. I do not want to expose "ASIO"
directly. I do not know if the final version I will use "ASIO" to handle
signals or if I remove this dependency.
E.g.: In version 0.3 I don’t use ASIO.

>>  I don't see how to control what signal a handler is responding to.

Well, here you have to choose in use defaults, or customize. The “default”
will hide all details, and will work on UNIX (Terminal/Daemon) and WINDOWS
(Console/Service) without modifications.
The default map is:

SIGINT, SIGTERM, SIGABRT will call handler defined on callback of
“termination_handler”, check:

https://github.com/retf/Boost.Application/blob/master/libs/application/examp
le/termination_handler.cpp

An exception is the “windows service”, which is mapped from events of SCM.

If you want to customize, you must take into consideration the type of
application and platform chosen. E.g. Windows Services don’t known anything
about SIGNALS,  in this case you need customize “aspects” handlers, on POSIX
you can use “aspects” handlers, “signal_manager” class, and/or self-pipe
aspect, check:

http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica
tion/customization.html#boost_application.customization.customize_signal

http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica
tion/posix_specifics.html#boost_application.posix_specifics.self_pipe_

>> I also don't really see why you would need to co-opt SIGUSR1; having both
USR1 and USR2 available for applications is important in some cases

Here user can change this, see:

http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica
tion/customization.html#boost_application.customization.customize_signal

Well, I can think in other way to do this here, user other signal. Do you
have any idea? Let me know!

>> Related to Boost.Asio integration, how would an application make use of
all the rest of that library (timers, sockets, etc.). It seems that a core
design principle ought to be that the full range of Asio capability would be
available.

You can have your own “io_service”, check this sample: 

https://github.com/retf/Boost.Application/blob/master/libs/application/examp
le/uuid_client_server/server.cpp

>> I am unclear about "aspects". It seems that in the simplest case any
class will work as an aspect. 

This is true.

>> In more complex cases a class must be derived from the aspect_contractor
abstract base class. 

Some aspects are used internally by application mode, then it need follow
one interface, that “application mode” will use. (“like a concept”)

>> Perhaps I missed it, but where is the aspect_contractor interface
documented? 

Sorry, I forgot to document each aspect abstract class interface. Here you
can have one idea:

http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica
tion/customization.html

>> More fundamentally, under what conditions will which aspect member
functions be called.

Some “aspect member functions” are called by “application mode” internally
on lib.

>>and what member functions must be provided for "any class" to actually
work in this capacity?

The abstract contractor class will tell you what you need provide to aspect
work internally on “application mode”.

>> Even more fundamentally, can you give some intuition regarding how you
see structuring an application in terms of different aspects interacting
with each other? 

Well, this is hard to say (Or better, I do not know the answer). In general
form, an application context pool, can have any number and types of aspects,
then you can design anything here.

Some aspects are needed by application mode, but you can make your own
application mode.

You have a lot of possibilities here!

>> Or, do you envision that the bulk of the application logic is independent
of your library classes, i.e., it resides in the user-provided application
operator function, and only small bits like termination signals would be
handled by the library? 

At this moment, I want more independent possibly. The use of aspects provide
this, we have all pieces separated, and we can tie all, in many ways.

E.g. The limit single instance is an aspect. And in future we can have one
aspect to TCP/IP for sample, that use asio, or other thing. I don’t know.

>> I guess I am confused about your vision of how a large, complex
application would be structured if it were to make use of your library. 

If you check lib design, you will see, that lib is composed by a many
independents pieces of code, that are tied at run time.

http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica
tion/design_overview.html

The lib provides the more “usual” features in ready to use form, but you can
customize any piece, and tie in any way that you want. 

If this large application is very complex, you can decompose it in many
aspects, and you can make one “custom application mode”, and you can use
some of ready to use aspects on it too. 

To give you the right answer, I need know more about this application. Is
hard to say.

In my personal experience (little experience), I already used this lib (0.2,
0.3 and 0.4) on Client service, MPI cluster (for credit card processing), on
TCP/IP (ASIO Based) Server (Daemon mode).
All using plug-in system (that are provided by library too).

>> What would be the division of labor between library-related classes
(including user-derived library classes) and independent user-provided code?

Check this:

http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica
tion/design_overview.html

This clarifies a little?

Well, The user can use singularity and get access to context in any location
too.

>> Finally, note that the links to your example files do not work.

This is true, the documentation was generated by quickbook, and don’t work
on my server, you need check code on github. Sorry!

Well, one question. Do you think that this library can be useful?

Sorry my english is not very good (is very bad), if any thing is not clean
let me know!

--
Renato