Since I've been told that a picture is worth a thousand words, here's how the registration process will look like:

The way we are planning to implement this is to develop the server side, and then distribute a devTool that will install all the necessary code on the tool the developer is working on, all this trough an easy and assisted process.

The developer will be able to customize the authentication scheme, according to its needs.

Now a few details:

• At startup a protected script will check if the serial number is properly formed. If the serial number will be missing the tool will show a registration dialog.

• Depending on how the developer has set up the registration process, tools might require a serial number to work or might just show a registration dialog with [register now] and [register later] (in other words: each developer will decide if the registration is mandatory or not)

• When the user will click the [register now button], he will be sent to a specific page for the tool on the register.xml-rpc.it site, containing the registration form. Here's an example of a registration page.

• In the registration page each developer will be free to ask any questions he likes (at least at the beginning, the registration pages will be created by evectors), except the first three lines of the form which will always be name and email address.

• Registering the product will also make the user a member of the site, meaning that when registering a new tool he will be recognized and the new registration will be added to his/her profile.

• Server side, the user profile will look something like this:
  
  Each developer will have access to the personalInfo of users who registered his tool and to the information stored in the specific tool section.

• Once the registration form will be completed, an email message with the S/N will be sent to the user, and the browser will be redirected to a local page where to input the serial number.

• Entering the serial number for the first time will also trigger an xml-rpc call to the server, and a flag "activated" will be set in the user profile. No personal data will ever be exchanged between radio and the server without the user knowledge and approval.

• Part of the user profile will also be saved in a PostgreSQL table on the updates server that we'll use to manage updates. In the table we'll store:

  [ user | serialnumber | toolName | expiration date | flActive ]

• At each update of the tool, the server will verify user, serialnumber and expiration date. If everything will be ok, the server will deliver the update. The expiration date will be set at the registration (each developer will be able to decide expiration timing), a missing expiration date will mean never expiring tool. There will be an optional "active" flag that could be used to block the update for any reason.

• In case of update failure, the error messages will be retreived from the tool sitting on the server, meaning that each developer will be able to manage error messages on his own.

• Developers will be able to update tools on the server via WebEdit. Developers' WebEdit accounts will allow them only to edit their own tools (webEdit access is restricted server side).

• Notice the yellow circle with the XML-RPC connection? There will be APIs to register users with the system from another server. This is where we are going to hook up our own e-commerce site.

So far, we have built the system in order to let each developer manage his own tools on this server. What to do with the gathered data is something that we will have to decide together.

For comments and suggestions click here , or, better, post them to your weblog and then send me a link ";->"