New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VSGI loader for GModule-based applications #130

Merged
merged 4 commits into from Jan 7, 2017

Conversation

Projects
None yet
3 participants
@arteymix
Member

arteymix commented Sep 13, 2015

This PR provides a new utility named vsgi to serve application written as a GModule using any supported server technology (soup, scgi and fastcgi)

If libapp.so is installed in standard location:

vsgi app:app

Server-specific arguments are passed after the --

vsgi app:app -- --port=3003

The only constaint for a compliant application is to provide a symbol following the ApplicationCallback delegate.

using VSGI;

public void app (Request req, Response res) {
    // ...
}

GModule provides static loading and unloading with g_module_check_init and g_module_unload symbols.

@arteymix arteymix self-assigned this Sep 13, 2015

@arteymix arteymix added this to the 0.3.0 milestone Sep 13, 2015

@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Sep 14, 2015

Member

The --application-id option requires the VSGI.Server to accept null application identifiers.

Member

arteymix commented Sep 14, 2015

The --application-id option requires the VSGI.Server to accept null application identifiers.

@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Oct 2, 2015

Member

The vsgi program should have a proper manpage.

The error message should be more helpful and propose a call with --help to obtain more details.

Member

arteymix commented Oct 2, 2015

The vsgi program should have a proper manpage.

The error message should be more helpful and propose a call with --help to obtain more details.

@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Dec 5, 2015

Member

With the rebase, vsgi is now statically bind with libvalum.

Member

arteymix commented Dec 5, 2015

With the rebase, vsgi is now statically bind with libvalum.

@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Dec 5, 2015

Member

Just a note: the GModule init loading and unloading can be used to perform live reloading.

Member

arteymix commented Dec 5, 2015

Just a note: the GModule init loading and unloading can be used to perform live reloading.

arteymix added a commit that referenced this pull request Jan 11, 2016

Build separate libraries for VSGI implementations
Organize sources in multiple folders to simplify the build and reduce
dependencies.

 - isolate the use of 'fcgi.h' for 'vsgi-fastcgi'
 - isolate the use of 'gio-unix-2.0' for 'vsgi-cgi'
 - provide a pkg-config file for each implementation

Each VSGI implementation is built as a 'TypeModule' and define the
'plugin_init' symbol to load its 'Server' implementation. This will be
used along with the loader described in #130.

Rename 'Soup' for 'HTTP' to avoid a *dirty* namespace conflict.

Extract the test implementation of VSGI under the name of 'VSGI.Mock'.

arteymix added a commit that referenced this pull request Jan 11, 2016

Build separate libraries for VSGI implementations
Organize sources in multiple folders to simplify the build and reduce
dependencies.

 - isolate the use of 'fcgi.h' for 'vsgi-fastcgi'
 - isolate the use of 'gio-unix-2.0' for 'vsgi-cgi'
 - provide a pkg-config file for each implementation

Each VSGI implementation is built as a 'TypeModule' and define the
'plugin_init' symbol to load its 'Server' implementation. This will be
used along with the loader described in #130.

Rename 'Soup' for 'HTTP' to avoid a *dirty* namespace conflict.

Extract the test implementation of VSGI under the name of 'VSGI.Mock'.

arteymix added a commit that referenced this pull request Jan 11, 2016

Build separate libraries for VSGI implementations
Organize sources in multiple folders to simplify the build and reduce
dependencies.

 - isolate the use of 'fcgi.h' for 'vsgi-fastcgi'
 - isolate the use of 'gio-unix-2.0' for 'vsgi-cgi'
 - provide a pkg-config file for each implementation

Each VSGI implementation is built as a 'TypeModule' and define the
'plugin_init' symbol to load its 'Server' implementation. This will be
used along with the loader described in #130.

Rename 'Soup' for 'HTTP' to avoid a *dirty* namespace conflict.

Extract the test implementation of VSGI under the name of 'VSGI.Mock'.

arteymix added a commit that referenced this pull request Jan 11, 2016

Build separate libraries for VSGI implementations
Organize sources in multiple folders to simplify the build and reduce
dependencies.

 - isolate the use of 'fcgi.h' for 'vsgi-fastcgi'
 - isolate the use of 'gio-unix-2.0' for 'vsgi-cgi'
 - provide a pkg-config file for each implementation

Each VSGI implementation is built as a 'TypeModule' and define the
'plugin_init' symbol to load its 'Server' implementation. This will be
used along with the loader described in #130.

Rename 'Soup' for 'HTTP' to avoid a *dirty* namespace conflict.

Extract the test implementation of VSGI under the name of 'VSGI.Mock'.

arteymix added a commit that referenced this pull request Jan 11, 2016

Build separate libraries for VSGI implementations
Organize sources in multiple folders to simplify the build and reduce
dependencies.

 - isolate the use of 'fcgi.h' for 'vsgi-fastcgi'
 - isolate the use of 'gio-unix-2.0' for 'vsgi-cgi'
 - provide a pkg-config file for each implementation

Each VSGI implementation is built as a 'TypeModule' and define the
'plugin_init' symbol to load its 'Server' implementation. This will be
used along with the loader described in #130.

Rename 'Soup' for 'HTTP' to avoid a *dirty* namespace conflict.

Extract the test implementation of VSGI under the name of 'VSGI.Mock'.

arteymix added a commit that referenced this pull request Jan 11, 2016

Build separate libraries for VSGI implementations
Organize sources in multiple folders to simplify the build and reduce
dependencies.

 - isolate the use of 'fcgi.h' for 'vsgi-fastcgi'
 - isolate the use of 'gio-unix-2.0' for 'vsgi-cgi'
 - provide a pkg-config file for each implementation

Each VSGI implementation is built as a 'TypeModule' and define the
'plugin_init' symbol to load its 'Server' implementation. This will be
used along with the loader described in #130.

Rename 'Soup' for 'HTTP' to avoid a *dirty* namespace conflict.

Extract the test implementation of VSGI under the name of 'VSGI.Mock'.
@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Jan 12, 2016

Member

This should be rebased upon 3b94bb8 to load VSGI implementations dynamically.

Member

arteymix commented Jan 12, 2016

This should be rebased upon 3b94bb8 to load VSGI implementations dynamically.

@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Jan 30, 2016

Member

It would be nice to support SIGHUP for reloading.

Member

arteymix commented Jan 30, 2016

It would be nice to support SIGHUP for reloading.

arteymix added a commit that referenced this pull request Feb 4, 2016

Fix #154 Remove 'INCLUDE_TYPE_MODULE' definitions
The shared library and modules (with '[ModuleInit]') cannot be the same,
because they don't have the same initialization strategy for registering
'GObject' types.

It will have to be solved with #130.
@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Feb 6, 2016

Member

Modules cannot be installed directly in lib.. They must be relocated in a specific folder like lib/vsgi/servers.

Member

arteymix commented Feb 6, 2016

Modules cannot be installed directly in lib.. They must be relocated in a specific folder like lib/vsgi/servers.

@arteymix arteymix referenced this pull request Feb 10, 2016

Closed

Configurable VSGI backend #164

arteymix added a commit that referenced this pull request Apr 24, 2016

vsgi: Remove 'plugin_init' symbols from implementations
Implementation as plugin should be addressed by #130.
@Bob131

This comment has been minimized.

Show comment
Hide comment
@Bob131

Bob131 Jun 1, 2016

Member

I just wanted to raise the possibility of some sort of configuration middleware whereby the vsgi utility could read from a config file rather than requiring CLI args, as well as passing some of those options onto the GModule app. Without such a mechanism, it seems as though daemonising apps with the need for their own configs with vsgi would become quite messy.

Member

Bob131 commented Jun 1, 2016

I just wanted to raise the possibility of some sort of configuration middleware whereby the vsgi utility could read from a config file rather than requiring CLI args, as well as passing some of those options onto the GModule app. Without such a mechanism, it seems as though daemonising apps with the need for their own configs with vsgi would become quite messy.

@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Jun 1, 2016

Member

The CLI is only a facility for passing arguments and setting up the server minimally. I added the listen and fork call a few weeks ago to make that simpler.

Each implementation interpret its options as a Variant object, so it could be possible to specify a config blob to load. However, doing so would mean to ignore arguments passed the -- delimiter.

vsgi --config some-blob.bin app:app

That would require tools for converting JSON (or any useful format) to GVariant.

Member

arteymix commented Jun 1, 2016

The CLI is only a facility for passing arguments and setting up the server minimally. I added the listen and fork call a few weeks ago to make that simpler.

Each implementation interpret its options as a Variant object, so it could be possible to specify a config blob to load. However, doing so would mean to ignore arguments passed the -- delimiter.

vsgi --config some-blob.bin app:app

That would require tools for converting JSON (or any useful format) to GVariant.

@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Jun 1, 2016

Member

I plan to first convert server implementations to GModule and then merge this PR.

We should have something like that instead (given /usr/lib64/vsgi/servers/libvsgi-http.so):

Server.@new ("http", "org.valum.Example", () => {});

Also some ServerModule API to handle more customizable use cases.

Member

arteymix commented Jun 1, 2016

I plan to first convert server implementations to GModule and then merge this PR.

We should have something like that instead (given /usr/lib64/vsgi/servers/libvsgi-http.so):

Server.@new ("http", "org.valum.Example", () => {});

Also some ServerModule API to handle more customizable use cases.

@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Jun 4, 2016

Member

The work should be rebased on #182. It will remove the hard-coded implementation switch.

Member

arteymix commented Jun 4, 2016

The work should be rebased on #182. It will remove the hard-coded implementation switch.

@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Jul 19, 2016

Member

Having a HandlerCallback signal defined in the module is not very practical because we have to initialize everything statically. I think that it would be best to define a ModuleCallback as follow:

public delegate ApplicationCallback ModuleCallback ();
public ApplicationCallback my_modular_app () {
    // put shared states here (e.g. database pool)
    return (req, res) => {
        return res.expand_utf8 ("Hello world!");
    };
}

public ApplicationCallback my_modular_router () {
    var app = new Router ();

    app.get ("/", (req, res) => {
        return res.expand_utf8 ("Hello world");
    });

    return app.handle;
}
Member

arteymix commented Jul 19, 2016

Having a HandlerCallback signal defined in the module is not very practical because we have to initialize everything statically. I think that it would be best to define a ModuleCallback as follow:

public delegate ApplicationCallback ModuleCallback ();
public ApplicationCallback my_modular_app () {
    // put shared states here (e.g. database pool)
    return (req, res) => {
        return res.expand_utf8 ("Hello world!");
    };
}

public ApplicationCallback my_modular_router () {
    var app = new Router ();

    app.get ("/", (req, res) => {
        return res.expand_utf8 ("Hello world");
    });

    return app.handle;
}
@arteymix

This comment has been minimized.

Show comment
Hide comment
@arteymix

arteymix Jul 19, 2016

Member

There's a compiler bug preventing the use of ModuleCallback https://bugzilla.gnome.org/show_bug.cgi?id=768967

Member

arteymix commented Jul 19, 2016

There's a compiler bug preventing the use of ModuleCallback https://bugzilla.gnome.org/show_bug.cgi?id=768967

@arteymix arteymix removed this from the 0.3.0 milestone Oct 13, 2016

@arteymix arteymix added this to the 0.4.0 milestone Nov 18, 2016

arteymix added some commits Sep 12, 2015

VSGI loader for GModule-based applications
Provide a loader, namely 'vsgi-loader', for application written as a
GModule.  The syntax is similar to gunicorn and make it possible to pass
CLI arguments to the server.

    vsgi-loader module -- --port=3003

It loads the symbole from the module, and forward arguments and serve
the application. It does not work for CGI due to the one process per
request constraint.

The implementation arguments must be separated by a '--' to make a clear
distinction from 'vsgi' arguments.

The default server technology is libsoup-2.4 and another implementation
can be specified with the '--server' flag.

The directory where the shared library is stored can be specified with
the '--directory' flag, defaulting on system path.

It support a built-in reloader based on 'GLib.FileMonitor' and
automatically reload the shared library on change.

Update documentation for loadable applications

Improve the section by covering more aspects with code examples.
@codecov-io

This comment has been minimized.

Show comment
Hide comment
@codecov-io

codecov-io Jan 7, 2017

Current coverage is 64.60% (diff: 36.58%)

Merging #130 into master will increase coverage by 3.91%

@@             master       #130   diff @@
==========================================
  Files            42         43     +1   
  Lines          1333       1373    +40   
  Methods           0          0          
  Messages          0          0          
  Branches        156        161     +5   
==========================================
+ Hits            809        887    +78   
+ Misses          476        422    -54   
- Partials         48         64    +16   

Powered by Codecov. Last update e35fe71...bba1410

codecov-io commented Jan 7, 2017

Current coverage is 64.60% (diff: 36.58%)

Merging #130 into master will increase coverage by 3.91%

@@             master       #130   diff @@
==========================================
  Files            42         43     +1   
  Lines          1333       1373    +40   
  Methods           0          0          
  Messages          0          0          
  Branches        156        161     +5   
==========================================
+ Hits            809        887    +78   
+ Misses          476        422    -54   
- Partials         48         64    +16   

Powered by Codecov. Last update e35fe71...bba1410

@arteymix arteymix merged commit d0cac01 into master Jan 7, 2017

0 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details

@arteymix arteymix deleted the loader branch Jan 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment