C++ framework design

[Chicken McNuggets]

Hi,

I'm working on a C++ web framework as a hobby project and am looking for
some advice on the best way to design it.

Currently my plan is the following:

* Create a Unix daemon which loads a set of configuration files which
specify the location of a group of shared libraries (and other settings).

* The daemon then forks enough processes so each configuration file is
associated with a single process.

* Each process then loads its dynamic library using dlopen().

* Once the dynamic library has been loaded a pre-determined entry point
is called in each dynamic library which returns the required information
to the main daemon.

* The daemon then uses that information to start using the dynamic
library to execute the client supplied code.

Does that sound like a decent idea of how to go about creating a C++
framework or can anyone provide some hints or tips for the best method
to use in this case?

 

[Ian Collins]

Hi,

I'm working on a C++ web framework as a hobby project and am looking for
some advice on the best way to design it.

Currently my plan is the following:

* Create a Unix daemon which loads a set of configuration files which
specify the location of a group of shared libraries (and other settings).

* The daemon then forks enough processes so each configuration file is
associated with a single process.

* Each process then loads its dynamic library using dlopen().

* Once the dynamic library has been loaded a pre-determined entry point
is called in each dynamic library which returns the required information
to the main daemon.

* The daemon then uses that information to start using the dynamic
library to execute the client supplied code.

Does that sound like a decent idea of how to go about creating a C++
framework or can anyone provide some hints or tips for the best method
to use in this case?

You don't say what the purpose of your framework is.

 

[Chicken McNuggets]

Sorry, I overlooked the word "web framework". Still, it might actually
be easier to use processes - i.e., CGI. FastCGI comes to mind and the
question, why on earth you are not using an existing web server.

Am 22.03.13 08:43, schrieb Christian Gollwitzer:

Sorry I should have been clearer. The framework is a web framework as
you say and it will be based on FastCGI but you are getting confused
between a web server (HTTP) and a FastCGI server which communicates with
a FastCGI client which is also normally the HTTP server.

For example Nginx is an HTTP server and also a FastCGI client. It
receives HTTP requests and translates them into a FastCGI request which
is sent to the FastCGI server (my daemon) the FastCGI server then
processes the request and sends a response back to the FastCGI client
(Nginx). The FastCGI client then transforms the FastCGI response and
sends it back to the HTTP client (the web browser) as an HTTP response.

FastCGI is a protocol that keeps the process alive between requests
hence the requirement for a daemon. Keeping it running all the time
reduces the need for start up and shut down costs (as is the case with
traditional CGI apps) and also allows persistent connections which is
also more efficient.

As for the reason I am writing a web framework in C++? I'm simply doing
it as a hobby.

Basically my daemon is intended to provide a simple framework that
people then hook in their own views and data (from a database or some
other source). I was planning to allow people to just write a simple
library that the daemon then loads at runtime and it then passes FastCGI
requests to the correct view in the library. The library then contains
all the code required to access the data sources and then the framework
simply takes the return value of the view and passes it back to the
FastCGI client in a form which can be returned to a browser.

I'm fairly certain that post is not particularly clear but if there is
anything I have missed out or you need some more information then let me
know. I'm in a bit of a rush at the moment.

 

[Jorgen Grahn]

....
You don't say what the purpose of your framework is.

Put differently: IMO it's suicide to design a framework or an API
without at the same time designing at least one non-toy, real
application which uses it.

/Jorgen

 

[Victor Bazarov]

Put differently: IMO it's suicide to design a framework or an API
without at the same time designing at least one non-toy, real
application which uses it.

"Suicide"? It can be a waste of time. It can be laden with
frustration. It can mean more work later (re-working and re-designing
is often more laborious than doing it correctly from scratch). But
"suicide"? Come on!...

V

 

[Öö Tiib]

Put differently: IMO it's suicide to design a framework or an API
without at the same time designing at least one non-toy, real
application which uses it.

I suspect that suicide is too strong term here. Sounds almost like
"watching TV is suicide". OP is making a solution without solving
any actual problems as a hobby. That is usually not too productive.
Hobbies must not be productive.

 

[woodbrian77]

"Suicide"? It can be a waste of time. It can be laden with

frustration. It can mean more work later (re-working and re-designing

is often more laborious than doing it correctly from scratch). But

"suicide"? Come on!...

Maybe unintentional suicide. Being foolish leads to
death sometimes.

Brian
Ebenezer Enterprises - an ounce of prevention is worth
more than a pound of cure.
http://webEbenezer.net

 

[Luca Risolia]

I'm fairly certain that post is not particularly clear but if there is
anything I have missed out or you need some more information then let me
know. I'm in a bit of a rush at the moment.

The steps you mentioned in your original question are a valid starting
point, although I would not fork the daemon from within the daemon
itself. I would rather use a second, external component for reading the
entries in the configuration file and spawning the corresponding daemons
by passing all the informations needed to identify the correct plug-in
to load.

 

[Chicken McNuggets]

Maybe unintentional suicide. Being foolish leads to
death sometimes.

Brian
Ebenezer Enterprises - an ounce of prevention is worth
more than a pound of cure.
http://webEbenezer.net

The problem I have at the moment is deciding on the best way to
integrate client code with the main framework. Once I have that figured
out the specifics of how the two sides will communicate will evolve as I
create a client library for testing. But until I have some method
figured out for the best method to load client code I can't really
create a client library to help develop the rest of the framework / API.

Basically I'm just looking for advice on common practice when it comes
to extending a C++ daemon with third party code. I'm not looking for
specifics of an API design as I haven't got that far yet.

 

[Jorgen Grahn]

"Suicide"? It can be a waste of time. It can be laden with
frustration. It can mean more work later (re-working and re-designing
is often more laborious than doing it correctly from scratch). But
"suicide"? Come on!...

It should be obvious that I didn't mean that literally, right?

/Jorgen

 

[Chicken McNuggets]

The steps you mentioned in your original question are a valid starting
point, although I would not fork the daemon from within the daemon
itself. I would rather use a second, external component for reading the
entries in the configuration file and spawning the corresponding daemons
by passing all the informations needed to identify the correct plug-in
to load.

That is an interesting idea. I'll look into that.

Thanks.

 

[Jorgen Grahn]

I suspect that suicide is too strong term here. Sounds almost like
"watching TV is suicide". OP is making a solution without solving
any actual problems as a hobby. That is usually not too productive.
Hobbies must not be productive.

True, but I don't want my hobbies to be disappointments, abandoned
because I lost interest or focus. I have made that mistake several
times, and that's why I commented.

Successful hobby projects are (for me) always the ones that are
useful. Preferably, they are useful before they are really finished --
that's a good incentive to finish them. A library or a framework needs
one (or more) actual applications to reach that stage. A bunch of
unit tests or a demo application is good, but not quite enough.

/Jorgen

 

[Victor Bazarov]

It should be obvious that I didn't mean that literally, right?

Well, yes, *that* was obvious. Suicide *literally* means death, and
unless the OP somehow is engaged in writing software for life-supporting
medical apparatus and is preparing to self-test it without even a trial
run under a debugger, would be *literally* suicide. Everything else it
not *literally* suicide, it's only *figuratively* suicide.

But then I don't agree with that, still. Writing API without a clear
specification in front of you (provided by that "real application which
uses it") is not even *figuratively* suicide. Sticking one's foot into
the adjacent public bathroom stall, as we know, is a political suicide
in a *figurative* sense. Betting your life savings on a horse known to
lose every race would be a suicide (in financial sense, and again,
figuratively). Writing an API? Really??

V

 

[Jorgen Grahn]

Well, yes, *that* was obvious. Suicide *literally* means death, and
unless the OP somehow is engaged in writing software for life-supporting
medical apparatus and is preparing to self-test it without even a trial
run under a debugger, would be *literally* suicide. Everything else it
not *literally* suicide, it's only *figuratively* suicide.

But then I don't agree with that, still. Writing API without a clear
specification in front of you (provided by that "real application which
uses it") is not even *figuratively* suicide. Sticking one's foot into
the adjacent public bathroom stall, as we know, is a political suicide
in a *figurative* sense. Betting your life savings on a horse known to
lose every race would be a suicide (in financial sense, and again,
figuratively). Writing an API? Really??

I'm not sure if you're just talking about (an unfortunate) choice of
words here, or if you really want to object to my claim ... ?
I'm interested in the latter only.

/Jorgen

 

[Jorgen Grahn]

.

The problem I have at the moment is deciding on the best way to
integrate client code with the main framework. Once I have that figured
out the specifics of how the two sides will communicate will evolve as I
create a client library for testing. But until I have some method
figured out for the best method to load client code I can't really
create a client library to help develop the rest of the framework / API.

Since I've generated so much noise elsewhere in this thread, I feel
obligated to try to answer your question ...

Basically I'm just looking for advice on common practice when it comes
to extending a C++ daemon with third party code. I'm not looking for
specifics of an API design as I haven't got that far yet.

Personally, I'd try to avoid that situation. "Plugins" seem so
confusing and error-prone[1]. If your software is free or open
source, how about letting people rebuild all of it to enable/disable
extensions, or add their own? Would that be feasible?

My next reaction would be "ok, if you do it, use a C API". These tend
to be more stable and well-defined.

[1] Disclaimer: I've never done this, neither badly nor well.

 

[Victor Bazarov]

I'm not sure if you're just talking about (an unfortunate) choice of
words here, or if you really want to object to my claim ... ?
I'm interested in the latter only.

"Object to" your "claim"? <sigh> What claim? Unfortunate choice of a
word? Probably. Do you actually have a claim? <shrug> If yes, you can
have whatever you claim there, I have no objection. If you stand by
your "choice of words", fine, everybody is entitled to their opinion,
however they choose to express it. Freedom of speech and all that...

V [walks away shaking his head]

 

[woodbrian77]

True, but I don't want my hobbies to be disappointments, abandoned

because I lost interest or focus. I have made that mistake several

times, and that's why I commented.



Successful hobby projects are (for me) always the ones that are

useful. Preferably, they are useful before they are really finished --

that's a good incentive to finish them. A library or a framework needs

one (or more) actual applications to reach that stage. A bunch of

unit tests or a demo application is good, but not quite enough.

I need to work on the "or more" part.
I'm willing to donate 15 hours a week for up to
six months on a project that uses the C++ Middleware
Writer.

Brian
Ebenezer Enterprises
http://webEbenezer.net

"Therefore, a person must endeavor to marry the
daughter of a Torah scholar, marry his daughter
to a Torah scholar, eat and drink with Torah
scholars, do business with Torah scholars..."