xendk / cim Goto Github PK

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).

Debug logging of communication would be very nice.

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).

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.

This is a reminder.

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

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

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

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

So admin can inspect the content of a changeset.

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

Common element for displaying the changes of a changeset.

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

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

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.

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.

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

Split out XMLRPC server stuff out from client code.

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

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

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