Overview
Features
Download
Documentation
Community
Add-Ons & Services

Dynamic component installation and updating.

Discussion of ideas for features and new projects based on POCO.

Dynamic component installation and updating.

Postby axilmar » 02 Dec 2011, 20:58

A functionality I wish I had was a way to lazily install and update a C++ application or parts of it on users' computers from a central location, either on a LAN, a VPN or a WAN, without any hassle for the user or administrator.

Windows C++ installations are monolithic, i.e. the user has to download the installation, run it, and then manage it by himself/herself, or call the system administrator which will have to install the application on each computer, along with all its dependencies, either by visiting or logging remotely. But this is usually done only on LANs or VPNs, and not on WANs.

In the Unix world, the need for automatic installation and updating of applications is taken care by package management systems, but the downloading and updating of individual components of an application is not done lazily and in the background. Granted, Unix provides good tools that can automate the job, but it requires a fair amount of work in order to work properly.

What I would like to see, as part of the POCO project, is a set of libraries and modules that allow me to:

  • write my application as one small executable and a set of DLLs.
  • post the executable and the DLLs to a server.
  • tell the user where to download the executable from.

From that point on, the user downloads the executable, and the following happens:

  • the user puts the executable in any folder he/she desires.
  • the user runs the executable normally, i.e. by double-clicking it from the GUI or launching it from the command line.
  • the executable downloads and installs the main DLL of the program automatically, and then loads it and runs it.
  • each time a DLL is requested to be loaded in the application space for the first time, the system automatically downloads and installs the appropriate DLL, if a new version is available in the server; otherwise, the local version is used.
  • the DLL maintenance mechanism can be extended to other types of data as well (pictures, sounds, etc).

While this capability does not strictly belong to POCO, POCO contains all the tools required for this code and data management (cryptography, servers, networking, etc).

Here is how I do envisage the code. For example, let's say I wish to write an application that accepts the user's name and prints 'hello world'. My main function would be:

Code: Select all
#include "HelloWorld.hpp"

RemoteModule<HelloWorld> helloWorld("192.168.1.15", 80);

int main() {
    string name = helloWorld.inputName();
    helloWorld.greetUser(name);
}


The HelloWorld.hpp header would contain the interface for the implementation:

Code: Select all
class HelloWorld {
public:
    virtual ~HelloWorld() {}
    virtual string inputName() = 0;
    virtual void greetUser(string name) = 0;
};


Suppose that initially, I do not need a GUI. I can then write an instance of HelloWorld that uses the command line:

Code: Select all
class ConsoleHelloWorld : public HelloWorld {
public:
    virtual string inputName() {
        string str;
        cin >> str;
        return str;
    }

    virtual void greetUser(string name) {
        cout << "hello " << name "!\n";
    }
};


Let's say a user downloads the executable. Then, the executable runs, the system downloads the main DLL, the DLL is loaded and executed, as specified by the code.

Suppose now I want to change the class to use a GUI. I then write a new DLL with this implementation:

Code: Select all
#include "GUILibrary.hpp"

RemoteModule<GUILibrary> guiLibrary("www.myguilibrary.com");

class ConsoleHelloWorld : public HelloWorld {
public:
    virtual string inputName() {
        SharedPtr<InputDialog> dialog = guiLibrary.new_<InputDialog>("Name:");
        dialog->doModal();
        return dialog->inputValue();
    }

    virtual void greetUser(string name) {
        guiLibrary::MessageBox::messageBox("Hello " + name + "!");
    }
};


With this system, I can post the new DLL in the server at address 192.168.1.15, and the next time the user runs the application, the following happens: the system sees that a new DLL is available from the specific server; the new DLL is downloaded and installed; the new DLL is loaded into the process and run; the user now sees the update.

So, what do you think? such a system could solve many issues. The above text only describes the main idea, of course.

POCO itself could be downloaded and managed via the same system. Such a system would attract a lot of people to POCO.

Thank you for your attention to this lengthy and unconventional post.
axilmar
 
Posts: 8
Joined: 02 Dec 2011, 19:42

Re: Dynamic component installation and updating.

Postby guenter » 03 Dec 2011, 17:19

Most of what is required for this is already implemented in our commercial OSP framework, so this would be a good starting point if you need this for a commercial application. You'll need to implement the check for bundle updates, but this is not too much work.
guenter
 
Posts: 1129
Joined: 11 Jul 2006, 16:27
Location: Austria

Re: Dynamic component installation and updating.

Postby axilmar » 05 Dec 2011, 13:41

Thank you, I had no idea this already existed.
axilmar
 
Posts: 8
Joined: 02 Dec 2011, 19:42


Return to Wishlist

Who is online

Users browsing this forum: No registered users and 1 guest