Application

Library Submission

Note: you must be a logged in registered user in order to submit a library!
  • logo_linkweb_linkcomment 
    Add a row
Display Statistics
Reviews There are 0 reviews
There are 7 comments

Comment on This Page

  • Matt C says:

    So I have been browsing over the documentation, and can see several points in which I have had to use or implement similar things in either professional or hobby code, so I can immediately see the utility of many of the features, and can imagine myself using them. Comments in no particular order:

    * Really glad that the DLL/SO features were factored out to Boost.Plugin. I’m excited about that functionality too!

    * I see that there is an application::args feature. I’m a fan of Boost.ProgramOptions. Is there a way for these to co-exist?

    * It wasn’t until the code at the bottom of “Application Apects” (sic) that I understood what an Aspect was in this context, even though it had been talked about for several pages. Aspects are introduced in the Motivation section, and the information that is most prominent about them at that point is that they were proposed by Vicente J. Botet Escriba. Attribution is all very well, but I would have liked the motivating example below that to actually show some usage, especially since I think aspects are probably one of the killer features of the library.

    * In “Using Application Handlers”, you have the sentence that begins: “Note that handlers must return a ‘bool’ to indicate to ‘application mode engine’, …” and I have no idea what it means to have something application mode engined.

    * In fact, and no disrespect to you since I understand very well exactly how difficult it is to do technical writing in a second language, you could probably do with the documentation being proof-read by a native English speaker.

    * The reference is a breadth-first search by header. IMO, this is one of the worst ways to arrange references. The location of a header file in a filesystem is only a tiny implementation detail. I would consider looking at the Boost.Asio reference documentation, which (again, IMO) is a superb arrangement.

    • Renato Forti says:

      Hi Matt,
      Thanks for your comments; they are very important to me!

      Answering your questions:

      >> I see that there is an application::args feature. I’m a fan of Boost.ProgramOptions. Is there a way for these to co-exist?
      Yes, in fact ‘application::args’ is only a wrapper for args, see:

      // …
      boost::shared_ptr myargs = context.find();

      po::options_description install(“service options”);
      install.add_options()
      (“help”, “produce a help message”)
      (“,i”, “install service”)
      (“,u”, “unistall service”)
      (“name”, po::value()->default_value(mypath->executable_name().stem().string()), “service name”)
      (“display”, po::value()->default_value(“”), “service display name (optional, installation only)”)
      (“description”, po::value()->default_value(“”), “service description (optional, installation only)”)
      ;

      po::variables_map vm;
      po::store(po::parse_command_line(myargs->argc(), myargs->argv(), install), vm);
      // …

      Full code: https://github.com/retf/Boost.Application/blob/master/example/simple_server_application.cpp#L197

      >> Attribution is all very well, but I would have liked the motivating example below that to actually show some usage, especially since.
      Well, “aspects” is a central concept on “application” they are used internally and hold many things like, application status, application type and so on.

      >> I think aspects are probably one of the killer features of the library.
      Sorry, what you mean? “aspects” is a good or bad thing of lib in your view? Please give more detail of your view.

      >> In fact, and no disrespect to you since I understand very well exactly how difficult it is to do technical writing in a second language, you could probably do with the documentation being proof-read by a native English speaker.
      Sorry, this is recurrent problem, many people advise me about the ‘Wrong English’.
      The problem is that the library is changing a lot, then I am waiting to pay some native to revise it.

      >> * The reference is a breadth-first search by header. IMO, this is one of the worst ways to arrange references. The location of a header file in a filesystem is only a tiny implementation detail. I would consider looking at the Boost.Asio reference documentation, which (again, IMO) is a superb arrangement.

      I will take a look, thanks 😉

      • Matt C says:

        Thanks for your response! Great to know that it hooks into ProgramOptions so easily, and that you’ll give serious consideration into the language quality of the documentation.

        >> >> I think aspects are probably one of the killer features of the library.
        >> Sorry, what you mean? “aspects” is a good or bad thing of lib in your view? Please give more detail of your view.

        By “killer feature”, I mean, “thing that distinguishes your library from others and makes me want to use it.” It’s a good thing.

        The problem I was trying to explain is that there were seven or so pages between the abstract introduction of the term “Aspect”, and the first time it’s used in code, where I didn’t quite understand what the documentation said. Once I saw the code, I understood what was meant, and then had to go re-read those pages in order to re-process them and finally understand.

        It’s a bit like how template arguments work, really.

        Conclusion: I think the documentation would be improved greatly by having a code example that uses aspects closer to where the term is introduced.

        • Matt C says:

          On reflection, I see that the example near the motivation does use an aspect: the arguments. I wonder why I blanked it so badly.

          • Renato Forti says:

            Hi Matt,

            Anyway, improve docs is on my TODO list. Please if you find any bug or problem let me know, and thanks a lot for your comment.
            If you have linkedin, please add me! https://www.linkedin.com/profile/view?id=29517985

  • tommy80486 says:

    Please find below my observations I made while reading through
    the documentation and source:

    When I first saw the description, I immediately thought it was a very general
    Application command-line/GUI framework because it was called Application.

    I immediately thought it was either:

    * A GUI framework
    * A generic application event loop mechanism
    * A way to create cross platform command line applications

    After reading the full description, it seemed to make more sense. I
    concluded it was a library for creating cross platform services, daemons,
    and other kinds of long running programs.

    After I read further into the documentation and code examples, I then
    found the Application Type. I then realized it was a library for creating
    any kind of application.

    It took me around 20 minutes to figure all this out. After I read
    the documentation and looked at the source.

    If I were to look for a library to create cross platform daemons or services,
    I would search for “C++ server library”. The library will attract more users
    if the library is more focused on the single purpose of creating
    server processes.

    Did you consider the name Boost.Service or Boost.Server?

    You might do your own survey. Ask a few people what they think a library
    called Boost.Application would do without any further description. And
    then ask the same person what they think a library called Boost.Server
    does without further description.

    If the library was focused only on server processes, the application_type
    identifier could be renamed to server_type. Then, it is more clear that
    server_type refers to how the server is implemented (e.g. A windows
    service/daemon, FastCGI, a thread in another process, etc.).

    I really think you have a great idea here and just need to make it a more
    focused library on creating server processes that can be implemented in a
    variety of ways based on server_type.

    We definitely need a way to create cross platform server processes.

    • Renato Forti says:

      Thanks a lot for your comments,

      >> It took me around 20 minutes to figure all this out. After I read the documentation and looked at the source.

      I will try let documentation more clear, for quickly understand.

      >> I would search for “C++ server library”. The library will attract more users if the library is more focused on the single purpose of creating server processes.

      This is the problem, the library is not focused on server, we have initially 2 kinds of application “common” and “server”, but we can have any type.
      The “server” type is more addressed type on documentation, because it is more usual for final user. A terminal application is easy to do, but server is more hard.

      >> Did you consider the name Boost.Service or Boost.Server?

      Well, I had a discussion about it in Boost ML, most think that name should be “application”. But I think that “Review” will direct this.
      I think that “Boost.Server” add other responsibilities to lib, like thread pool that I cannot address. And directs the lib to only one direction!

      >> I really think you have a great idea here and just need to make it a more focused library on creating server processes that can be implemented in a variety of ways based on server_type.

      Thanks a lot :O), I will consider your comments.