We recently unveiled an important feature in version 6 of the Passenger application server. Passenger 5 supports Ruby, Python and Node.js, but v6 will support all programming languages. We call this effort generic language support, or "GLS" for short.

Artwork for Passenger 6, to be released.

We held a coding livestream and Q&A session on November 1st. The session didn't only show the feature being implemented, but it also explained Passenger's code and architecture. Questions such as the following were answered:

  • What does the code that's being written, actually do?
  • How does it fit in the architecture?
  • What are caveats (e.g. security) to look out for?
  • What patterns does Passenger use to ensure high performance?
  • How do certain C++ language features compare to other languages like Ruby, JavaScript, Java, etc.?

Today, we are publishing its recording, presentation files and diagrams. Scroll down in this blog post and you will find a table of contents, as well as a highlights review for the recording.

(see table of contents below)

What do you think of GLS? How would you use it? Join the discussion on Github, discuss on Hacker News or send us a Tweet!

1. Introductory presentation

The video begins with an introductory presentation (until 15:58) which covers:

  1. Motivation and goal
  2. Passenger architecture 101
  3. The implementation plan

You can also find the presentation on Slideshare.

1.1. Motivation and goal

1.2. Passenger architecture 101

2. Coding session

The coding session starts at 15:58 and consists roughly of these parts:

  1. Apache integration mode (plus some shared code)
  2. Nginx integration mode
  3. Standalone mode
  4. Core Controller, ApplicationPool and SpawningKit
  5. Single-app mode (for Standalone mode + builtin engine)
  6. Compile and test

2.1. Apache integration mode

2.2. Nginx integration mode

2.3. Standalone mode

At [position 1:35:02 in the video], we modify Passenger Standalone with the necessary changes. This mostly consists of adding the necessary configuration options.

Recall that Passenger Standalone (when using the default 'nginx' engine) just runs Passenger+Nginx under the hood. So this part demonstrates how to edit the internal Nginx config template.

This part also shows — when Passenger is used with the 'builtin' engine) — how to modify the Passenger Core CLI arguments in order to receive the new config options.

2.4. Core Controller, ApplicationPool and SpawningKit

With all the necessary changes made in the integration mode components, it's time to modify more fundamental parts of Passenger.

2.5. Single-app mode

At position 2:10:16 of the video, we describe the single-app mode, which is activated when Passenger Standalone is configured to use the 'builtin' engine.

Special points of interest:

  • The ConfigKit framework (2:10:50)

    An internal framework for per-component configuration & schema composition.

    Passenger is architected as a collection of loosely-coupled components. Each component is designed to be as simple as possible, and could be relatively easily extracted to be used outside of the Passenger codebase. Complex behavior is obtained by composing multiple components.

    The configuration options supported in Passenger is thus a composition of the configuration options supported by each component. ConfigKit makes composing configuration options possible and robust, and introduces typechecking, compositional translation and validation.

    If you've used something like React, then you may know the pains of drilling-down props. This is also one of the problems ConfigKit addresses, though in a totally different way than e.g. Redux.

  • The single-app-mode initialization function & initial autodetection (2:24:55)

2.6. Compile and test

Finally, at position 02:34:55 of the video we compile Passenger and test the feature.

Join the discussion

What do you think of GLS? How would you use it? Join the discussion on Github, discuss on Hacker News or send us a Tweet!