One of the goals of Concerto 2 is a streamlined installation and setup - getting from a download to having a screen up and running should be as easy as possible. With that in mind, this page aims to detail the ways that a Concerto instance could me modified on a per-instance basis, short of heavy modifications to the core code of the system.

Switches and parameters

A central configuration object should be made globally available, and hold on to certain configuration parameters, which would induce modifications to the system's behavior. A couple of implementation options are available:

1. Plain text file: a YAML or Ruby file with simple parameter definitions could be edited by hand. This has the advantage of being simple and efficient, but would require file system access and some attention to parameters, limits, etc. to modify.

2. Database storage: a single row configuration object or a key-value store could hold configuration parameters in the database. If we took this route, it would be easy to edit from within the Concerto web front end, including providing dropdowns, limits, and tips for users. However, the potential impact on performance from needing to periodically query the DB should be evaluated.

Let's try to keep track of the things we might want to configure on a per-install basis.

This list is at least initially based on the Concerto 1 configuration parameters, viewable here.

• Preferred URL - the base domain (and optional path scope) to be used in places where an absolute path is needed, such as e-mail notifications.
• System Email Address
• Open Sign-up - Will users be able to sign themselves up and participate, or will they require an invite or at least confirmation?
• Notification configuration - This may pan out to include enabling digests, etc.
• Require SSL - The webserver will have to be configured to support SSL, but we can force rails to refuse requests when SSL is not in use.
• Default Content Duration - Is this still relevant? Yes. ~BAM
• Default Subscription Weight - Is this still relevant?
• Ticker Character Limit
• Media size limit
• Deletion policy - some instances may want to automatically remove old content.

Basic Rails configuration could still be handled through the traditional channels

• Database configuration in config/database.yml
• Advanced Caching

Additional topics for configuration include things related to Screen Hardware management, settings for plugins, and branding.

Concerto Modification

What sorts of heavy modifications do we foresee organizations needing? What can we do to make that easier? What can be implemented as a swappable "plugin"?

Different authentication methods

Likely, this will be not quite as simple as changing a configuration parameter, but with the Devise system being used for authentication, several swappable plugins are available to provide different authentication methods (generally requiring making a change to the Gemfile and adding a settings file).