xendk/cim

Moved to Drupal.org

cim's Issues

Encryption of communication

As the configuration can contain sensitive information, it must be protected from prying eyes.

While requiring the server to support SSL could be a solution, it's not good enough as it raises the bar for the end users, and we want to keep that as low as humanly possible.

So, some possibilities:
mcrypt
openssl (simple example in here: http://stackoverflow.com/questions/1391132/two-way-encryption-in-php )

The question is how widespread those PHP modules are.

Pure PHP lib: http://phpseclib.sourceforge.net/ (with fallback to mcrypt/openssl, if they're available).
PEAR packages: http://pear.php.net/packages.php?catpid=6

Show details of changeset

So admin can inspect the content of a changeset.

Split out code into more files.

Split admin pages dealing with upstream out from pages dealing with local snapshots.

Split out XMLRPC server stuff out from client code.

Listing of snapshots

Administration page to list all snapshots and do stuff to them.

Debug logging

Debug logging of communication would be very nice.

Revert a snapshot

Administrators shoud be able to revert the changes in a single snapshot.

Interface on master for receiving changeset from client.

Checking if the changeset is valid (Changeset::appliesTo()), rejecting it if not, or applying it otherwise (creating a new snapshot in the process).

Thinking XMLRPC is the straitforward protocol to use (we don't want external dependencies).

Way for dev site to hook up with prod/stg

Should be as easy as entering the URL of the master, which initiates a FB/Twitter/Google like 'app authentication' where the user is redirected to a login on the master (or skipping directly to the next step if already logged in), and being asked to confirm the hookup (if the user have the appropiate permissions, of course).

There'll be some key exchange done in the background for future communication, but it's important to remember that the client might only be reachable from the local machine (we assume that the client can always communicate with the master), so callbacks from the master is not an option.

Fetching of configuration from master

And applying the configuration to the client site, making a note of the snapshot for later creation of changesets.

Simplify as hell...

This is a reminder.

"The least amount of code that could possibly work".

Changeset widget

Common element for displaying the changes of a changeset.

Pushing should leave local changes in place.

Currently local changes get incorporated into the newly created snapshot. They should be reverted before snapshotting, and reapplyed afterwards. Or more elegantly be ignored in the applying of the pushed changeset stage.

Let changeset widget act as a value form item

To eliminate the dupe '#type' => 'value' item in every form.

Later on it might gain the capability of editing the changeset.

Creating a client changeset

From the difference between the last fetched master snapshot and the current client configuration, and pushing it to the master.

Rebase

When configuration has changed on upstream, there needs to be a way to pull the changes, but retain local changens.

Cleanup of Response class

It's a complete mess, which purpose was to avoid sending arrays back and forth.

After a push, downstream is out of sync

It still thinks that the upstream is at the previous sha.

Current know upstream sha is together with the local sha that gives the same configuration. However, currently it pushes all local changes, including those that haven't been snapshottet yet, so no local snapshot may exist.

Automatically creating a snapshot could fix it, but I'm not too fond of that.

Only pushing "up to" a given snapshot is another solution, but the UI needs to be tight, so it's obvious that it's "up to", and not just the given changeset. Both options could be handy, but the possibility for confusion is great (the difference between pushing a changeset and a snapshot is small).

Clean up terminology

We don't want the features situation where we have "feature components" and "feature sources" and code that unclear on what's it's referring to.... Starting point:

• Difference
  • One change of a config item.
• Changeset
  • A set of Differences.
  • Has a parent changeset.
  • Has an identifier (should it be renamed to SHA?).
• Snapshot (doesn't exist as an object, yet).
  • Contains a changeset
  • Possibly a full dump.
  • Date, maybe comment.
  • Should rename id and parent to changeset_id/parent, to avoid misunderstanding.
• SnapshotController
  • Keeps track of snapshots.

Needs work:

• SnapshotInterface
  • Not really an interface to snapshot.
• ArraySnapshot
  • Something different from the snapshots managed by the controller.
• Config
  • Bit too general a name.

SnapshotInterface -> ConfigInterface
ArraySnapshot -> ConfigArray
Config -> ConfigDrupalConfig (must avoid confusion with the DrupalConfig class).
perhaps?

And everything should be namespaced or prefixed.