Enable sites to post information on their modules, themes

One weakness of the approach I've used here is that, to try to provide a basis for a later query "what are the updated versions available of this module/theme/engine?", the description sent to drupal.org includes the filemtime() of each system file on the client system. But that's very limited.

In http://drupal.org/node/37927 we're considering using hashes of each project release file. Could/should we use the same here--only of each .module, .theme. and .engine file? We could generate these on drupal.org and store them in the cvs_files table. Then we could post hashes as part of the system module data. These would then be compared with the data on drupal.org to find the exact match.

Does this sound right?

Thanks for the thoughtful review Dries. It was a busy week and I didn't get a chance to focus on this. I'll work on a revised patch incorporating your suggestions.

What I've been hoping we might be able to do is to leave a door open to returning useful information to user sites on available updates etc. But, I agree, these things need to be carefully thought out and the window (another architectural metaphor) for doing so for 4.7 is closing. Perhaps developing some of this in a contrib module e.g. for CivicSpace over the 4.7 cycle would be useful, with a mind to refining and then moving features to core for 4.8.

Here's a revised patch following most of the suggestions.

* $cid is retained, but not returned to client.
* no messages returned to client
* no user id used
* data on client system limited to enabled components, changed time not sent
* other minor fixing up.

The last patch is my best attempt at a "do the minimum" approach, which is probably what's needed.

But for the sake of argument - or perhaps to begin sketching in what will probably be future improvements - here is another take on the "do the minimum, while still leaving a door open to sending client sites updates" approach.

Added to the previous patch is:

* configuration option to designate server as offering update information (by email). this information is by means of subscription.
* if this option is set on the server, a token is returned to the client, which then displays a message on the settings page. either (a) there is already an account for the site email on the XML-RPC server, in which case the client is prompted to log in, or (b) there is no existing account for the site email, so the client is prompted to register.
* once registered and logged in on the XML-RPC server, the client owner sees a new section on his/her user account edit page, 'Client site updates', where he/she can opt in.

So, this leaves a door open, without committing us to anything. If/when we're ready, we flip a switch on drupal.org and client sites can begin subscribing.

But - while perhaps better than my previous suggestion - this is only one of a number of possible approaches and I accept that we'll probably have to wait for 4.8 to do anything along these lines.

Here's an updated version of the patch at comment #5. I've added pgsql and update versions. For the update, I've just dropped the old directory table and added client and client system. This assumes there's no needed information in the old tables (that won't be replaced when clients reconnect). Valid assumption?

Also, I realize I haven't considered what will happen when old drupal.module versions try to connect. They'll be sending data in a way that the new drupal.module won't understand.

I don't think DELETE FROM {client_system} s INNER JOIN {client} c ON s.cid = c.cid is standard sql

Yep, thanks, it was wrong, now reworked.

Does table client_system really need to have primary key (cid, name)? You seem to use cid only

cid by itself won't be unique. The unique combination will be cid, name. (Unless we can have a module with the same name as a theme. Is this possible? If so, the primary key should be a combination of the three fields.)

Forgot to save my last changes before generating the patch, here's the right version.

Here's an (minimal version) updated patch. The only change (besides moving and renaming the update function) is an added test at the beginning of function drupal_client_ping():

  // Pre 4.7 versions sent data in a different format, no longer supported.
  if (!is_array($client)) {
    return FALSE;
  }

Just wondering, what will happen when someone sends an "old style ping"? This shouldn't generate errors, or render the database inconsistent. Looks like the patch needs another version to make this work right.

What I've done (change noted above) is return FALSE when past client versions attempt to register.

We could, alternately, add in support for past versions, but it would be a bit complicated. There were more arguments passed in previously, and of different data types. Since XMLRPC wants us to define the data types, I'm not sure how this would work. Maybe we would need two separate methods, one now deprecated but still supported for backward compatibility.

What happens when I change the name of my site? A new entry is inserted, and the old entry will expire, or will we end up with two entries?

Changing the name won't lead to two entries--the old name will be replaced with the new. Changing the base url will lead to two entries--until the old one expires due to lack of pings.

Thanks John for your insightful comments and detailed suggestions. It really helps to have someone go over a patch with such a careful eye to detail. Your suggestions certainly improve the "plain languageness" of the help text and field labels.

This revised patch incorporates John's suggestions and fixes (some I've adapted). I've also gone through the code again and made a number of small additional changes, mainly for clarity and consistency. Of note:

• Introduced a new theme function for the client listing. I also converted an inline CSS instruction to a class name ('indented'), adding the class name to an existing item in drupal.css (not sure if I chose appropriately). Yes, this listing functionality isn't currently in use on drupal.org, but it could be useful on other sites using the Drupal module and, if it's there, it should be consistent with other Drupal code.
• Changed the module description to emphasize its use in ranking modules and themes. New text: "Lets you register your site with a central server and improve ranking of Drupal projects by posting information on your installed modules and themes; also enables users to log in using a Drupal ID." (But is this too long/wordy?)

Why is "let users from other drupal sites log into my drupal site" here along with "send information about my drupal site to drupal.org?"

I assume what originally tied these together was that they are both implementations of inter-site communications.

I propose moving the remote authentication stuff into remoteauth.module and making the enable/disable remote authentication setting available on a tab when viewing user settings (when remoteauth.module is enabled).

Moving remote authentication might indeed make sense. It would obviously be a different (probably subsequent) patch.

Here is a new patch. I've:

• altered the fieldset labels in the settings page, dropping 'client' and 'server' references (now closer still to what John had suggested)
• used a definition list for the theme function.
  (thought: should we instead consider extending theme_item_list() so it could output dl lists as well as ol and ul ones?)
• used a define for the version.
  (thought: should this be in common.inc or possibly boodstrap.inc instead, so that it's available to other modules?

Maybe we're there, but if not I'm happy to make further tweaks.