Solar_Registry is a class for storing singleton objects which are used usually for things like SQL objects and the response and request objects. Now what's interesting, is that in the new version of Solar a new configuration key registry_set was added for the Solar arch-class. You can use it to tell Solar to automatically add objects to the registry when it starts up.

Normally you would register objects in your code, for example like this:

<?php
if (! Solar_Registry::exists('sql')) {
    Solar_Registry::set('sql', Solar::factory('Solar_Sql'));
}
?>

That would register an SQL object for you if not already registered. With the new registry_set configuration key you can make Solar register objects automatically for you when Solar::start() gets called. For registering the same SQL object you could just have this in your configuration file:

<?php
$config['Solar']['registry_set']['sql'] = 'Solar_Sql';
?>

One good example of registry_set is when it is used to set up Solar_Mail_Message so that it uses SMTP transport to send emails. Here's the full configuration:

<?php
// 1. configure SMTP
$config['Solar_Smtp'] = array(
    'adapter'  => 'Solar_Smtp_Adapter_NoAuth',
    'host'     => 'localhost',
);

// 2. register an SMTP connection object
$config['Solar']['registry_set']['smtp'] = 'Solar_Smtp';

// 3. configure mail transport
$config['Solar_Mail_Transport'] = array(
    'adapter' => 'Solar_Mail_Transport_Adapter_Smtp',
    'smtp'    => 'smtp',
);

// 4. register a transport object
$config['Solar']['registry_set']['mail_transport'] = 'Solar_Mail_Transport';

// 5. configure mail messages to use our mail transport
$config['Solar_Mail_Message']['transport'] = 'mail_transport';
?>

Let's go through it line-by-line.

First, configure Solar_Smtp to use no authentication and connect to localhost:

<?php
// 1. configure SMTP
$config['Solar_Smtp'] = array(
    'adapter'  => 'Solar_Smtp_Adapter_NoAuth',
    'host'     => 'localhost',
);
?>

Next, add an SMTP object to the registry for the key smtp:

<?php
// 2. register an SMTP connection object
$config['Solar']['registry_set']['smtp'] = 'Solar_Smtp';
?>

Now, configure the mail transport class to use the SMTP object we registered above:

<?php
// 3. configure mail transport
$config['Solar_Mail_Transport'] = array(
    'adapter' => 'Solar_Mail_Transport_Adapter_Smtp',
    'smtp'    => 'smtp',
);
?>

In other words, this tells Solar_Mail_Transport_Adapter_Smtp to get a Solar_Smtp object from the registry for key smtp.

Next, add a mail transport object to the registry for the key mail_transport:

<?php
// 4. register a transport object
$config['Solar']['registry_set']['mail_transport'] = 'Solar_Mail_Transport';
?>

Finally, tell Solar_Mail_Message to use registry key mail_transport to get a transport object.

<?php
// 5. configure mail messages to use our mail transport
$config['Solar_Mail_Message']['transport'] = 'mail_transport';
?>

Note that both of the registry objects we added are only instantiated when they are requested from the registry for the first time. This is also known as lazy-loading. For example, Solar_Mail_Message uses dependency-injection to get a transport object, like this:

<?php
$transport = Solar::dependency('Solar_Mail_Transport', 'mail_transport');
?>

The beauty of registering the objects in the configuration file is that we can very easily change to use transports other than SMTP for sending email. You could for example have different transports in development and production -- you then only need to modify the configuration file.