C++ framework design

Discussion in 'C++' started by Chicken McNuggets, Mar 22, 2013.

  1. 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?
     
    Chicken McNuggets, Mar 22, 2013
    #1
    1. Advertising

  2. Chicken McNuggets

    Ian Collins Guest

    Chicken McNuggets wrote:
    > 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.

    --
    Ian Collins
     
    Ian Collins, Mar 22, 2013
    #2
    1. Advertising

  3. On 22/03/13 08:57, Christian Gollwitzer wrote:
    > 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:
    >> Am 22.03.13 08:09, schrieb Chicken McNuggets:
    >>> 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.
    >>>
    >>> ...
    >> >
    >>> * The daemon then uses that information to start using the dynamic
    >>> library to execute the client supplied code.

    >>
    >> Yeah, but what is this good for? That is unclear to me.
    >>
    >> 1. Why do you need the daemon?
    >> For running a bunch of programs in parallel, just use a shell script.
    >> Maybe you want to do something like launchd on OSX, which schedules
    >> service providers? Look at dbus. Timetable? Use cron etc.
    >>
    >> 2.
    >> If you just want to schedule the start (like cron et al.), then why not
    >> use a main executable for the processes. It's a standardized interface
    >> and available for all languages on that platform. A shared lib only
    >> makes sens, if you want to call back into the daemon code. Even then, it
    >> might be better to use stdin/stdout for IPC.
    >>
    >> Christian

    >


    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.
     
    Chicken McNuggets, Mar 22, 2013
    #3
  4. Chicken McNuggets

    Jorgen Grahn Guest

    On Fri, 2013-03-22, Ian Collins wrote:
    > Chicken McNuggets wrote:
    >> 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:
    >>

    ....
    > 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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Mar 22, 2013
    #4
  5. On 3/22/2013 10:11 AM, Jorgen Grahn wrote:
    > On Fri, 2013-03-22, Ian Collins wrote:
    >> Chicken McNuggets wrote:
    >>> 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:
    >>>

    > ...
    >> 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.


    "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
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 22, 2013
    #5
  6. Chicken McNuggets

    Öö Tiib Guest

    On Friday, 22 March 2013 16:11:49 UTC+2, Jorgen Grahn wrote:
    > On Fri, 2013-03-22, Ian Collins wrote:
    > > Chicken McNuggets wrote:
    > >> 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:
    > >>

    > ...
    > > 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.


    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.
     
    Öö Tiib, Mar 22, 2013
    #6
  7. Chicken McNuggets

    Guest

    On Friday, March 22, 2013 9:20:23 AM UTC-5, Victor Bazarov wrote:
    > On 3/22/2013 10:11 AM, Jorgen Grahn wrote:
    >
    >
    > > 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!...
    >


    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
     
    , Mar 22, 2013
    #7
  8. Chicken McNuggets

    Luca Risolia Guest

    On 22/03/2013 13:50, Chicken McNuggets wrote:
    > 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.
     
    Luca Risolia, Mar 22, 2013
    #8
  9. On 22/03/13 15:34, wrote:
    > On Friday, March 22, 2013 9:20:23 AM UTC-5, Victor Bazarov wrote:
    >> On 3/22/2013 10:11 AM, Jorgen Grahn wrote:
    >>
    >>
    >>> 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!...
    >>

    >
    > 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.
     
    Chicken McNuggets, Mar 22, 2013
    #9
  10. Chicken McNuggets

    Jorgen Grahn Guest

    On Fri, 2013-03-22, Victor Bazarov wrote:
    > On 3/22/2013 10:11 AM, Jorgen Grahn wrote:
    >> On Fri, 2013-03-22, Ian Collins wrote:
    >>> Chicken McNuggets wrote:
    >>>> 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:
    >>>>

    >> ...
    >>> 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.

    >
    > "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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Mar 22, 2013
    #10
  11. On 22/03/13 17:08, Luca Risolia wrote:
    > On 22/03/2013 13:50, Chicken McNuggets wrote:
    >> 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.
    >


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

    Thanks.
     
    Chicken McNuggets, Mar 22, 2013
    #11
  12. Chicken McNuggets

    Jorgen Grahn Guest

    On Fri, 2013-03-22, Öö Tiib wrote:
    > On Friday, 22 March 2013 16:11:49 UTC+2, Jorgen Grahn wrote:
    >> On Fri, 2013-03-22, Ian Collins wrote:
    >> > Chicken McNuggets wrote:
    >> >> 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:
    >> >>

    >> ...
    >> > 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.

    >
    > 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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Mar 22, 2013
    #12
  13. On 3/22/2013 1:52 PM, Jorgen Grahn wrote:
    > On Fri, 2013-03-22, Victor Bazarov wrote:
    >> On 3/22/2013 10:11 AM, Jorgen Grahn wrote:
    >>> On Fri, 2013-03-22, Ian Collins wrote:
    >>>> Chicken McNuggets wrote:
    >>>>> 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:
    >>>>>
    >>> ...
    >>>> 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.

    >>
    >> "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?


    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
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 22, 2013
    #13
  14. Chicken McNuggets

    Jorgen Grahn Guest

    On Fri, 2013-03-22, Victor Bazarov wrote:
    > On 3/22/2013 1:52 PM, Jorgen Grahn wrote:
    >> On Fri, 2013-03-22, Victor Bazarov wrote:
    >>> On 3/22/2013 10:11 AM, Jorgen Grahn wrote:
    >>>> On Fri, 2013-03-22, Ian Collins wrote:
    >>>>> Chicken McNuggets wrote:
    >>>>>> 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:
    >>>>>>
    >>>> ...
    >>>>> 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.
    >>>
    >>> "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?

    >
    > 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 <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Mar 23, 2013
    #14
  15. Chicken McNuggets

    Jorgen Grahn Guest

    On Fri, 2013-03-22, Chicken McNuggets wrote:
    ....
    > 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.

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Mar 23, 2013
    #15
  16. On 3/23/2013 6:31 AM, Jorgen Grahn wrote:
    > On Fri, 2013-03-22, Victor Bazarov wrote:
    >> On 3/22/2013 1:52 PM, Jorgen Grahn wrote:
    >>> On Fri, 2013-03-22, Victor Bazarov wrote:
    >>>> On 3/22/2013 10:11 AM, Jorgen Grahn wrote:
    >>>>> On Fri, 2013-03-22, Ian Collins wrote:
    >>>>>> Chicken McNuggets wrote:
    >>>>>>> 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:
    >>>>>>>
    >>>>> ...
    >>>>>> 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.
    >>>>
    >>>> "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?

    >>
    >> 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.


    "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]
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Mar 23, 2013
    #16
  17. Chicken McNuggets

    Guest

    On Friday, March 22, 2013 6:04:42 PM UTC, Jorgen Grahn wrote:
    >
    > 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..."
     
    , Mar 24, 2013
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anatoly Volodko
    Replies:
    1
    Views:
    2,171
    Mattias Sjögren
    Aug 14, 2003
  2. Charles A. Lackman
    Replies:
    1
    Views:
    1,458
    smith
    Dec 8, 2004
  3. Mark
    Replies:
    4
    Views:
    1,753
    Juan T. Llibre
    Nov 17, 2005
  4. moi
    Replies:
    3
    Views:
    4,091
    quaiser_ali
    Sep 26, 2008
  5. Replies:
    2
    Views:
    9,372
    Darryl L. Pierce
    Sep 11, 2005
Loading...

Share This Page