I wrote previously that I had done some reasonably considerable work integrating Drupal with Second Life, which of course means integrating the Drupal System with the Linden Scripting Language.
LSL has the llHTTPRequest function, of course, by which one can send information to Drupal (or indeed any other system on the Wider Aethernet). The main issues that I have encountered, though, are:
The sum of data to be sent and received. A typical Drupal page is really quite enormous and unsuitable for the standard LSL limit of 4096 characters. Furthermore, many existing interfaces to web services, involving the XML or JSON formats, are unsuitable for use with LSL, which really takes an age to do any sort of String Processing. Both request and response need to be of very short formats.
The problem of authenticating who, indeed, the person sending the request is. Sending the registered Drupal username and password hash is quite a simple thing to do, but in most cases, this is unsuitable for use with LSL. People do not wish to have to enter usernames and passwords into scripts or notecards unless they absolutely cannot help it.
In the past, with Rezzable's "Avatar Linking" system, I solved this by giving the resident concerned the ability to create a Drupal user account for themselves if they did not already have one, automatically from the grid, with the entry of a few details such as their Email Address; the name and key of the resident was passed along with this, and stored in Drupal. Other Scripted Gadgets which they might use in future then authenticate themselves with some sort of Master Password, and pass the key of the operating avatar along with other data. The Drupal system looks the appropriate user account up by matching the key to stored and confirmed ones, and carries out operations for that user - for instance, leaving comments on the node for a particular Artwork.
Both of these are common issues across all sorts of Systems for which one would wish to use Drupal, and it occurs to me that a Common Framework would be useful in this instance. I am moved to create such a framework for my personal and professional use, and also the use of anyone else who might be interested.
The most important features of this framework (which I have been calling "Slight" - SecondLife Lightweight) as I seem them are
that it can receive data easily, pass them on to other modules for use, receive responses from those modules, and return the responses to an LSL script in a format that can be quickly processed and understood;
that it has the ability to authenticate users and pass the details of the authenticated user on to sundry other Drupal systems. This authentication could be performed by the main module itself as well as other, optional ones which folk might choose to write.
Those familiar with the Drupal Beast will be aware of the concept of a "hook". Invoking a hook allows other modules which are aware of it to perform actions on data passed along with that hook. I am thinking along the lines of having two hook invocations here - firstly, one for authentication, which passes along the data sent and allows other modules to modify a user object. Then, one for the action to be performed, which allows modules to perform actions on the basis of those data and the authenticated user, and add responses, which will be passed back to the LSL script to be delivered to the resident.
Perhaps an example might be of use here. Say one wishes to have a system which allows the creation of "blog" entries via LSL. The LSL script would take the key of the avatar (this is unforgeable) and combine it with a hardcoded password to produce a hash. It would send this to the Slight interface - which possesses a specific URL, say http://ordinalmalaprop.com/engine/interface/slight/ - along with the avatar's key in plain text, and the actual text of the blog entry. Our Drupal administrator here has three relevant modules installed - the Slight framework module, a Slight Second Life authentication module, and a Slight blog entry module.
Slight would initially believe this entry to be unauthenticated, as there would be no information as to the Drupal username and password. It would, however, invoke a hook for authentication with a missing user object, giving other modules the opportunity to authenticate whoever it was. "Aha!" the Slight Second Life authentication module says, "this person has sent a hash of key and master password which I recognise - I will modify the user object to correspond to the user whose avatar has this key". And it proceeds to do so.
Upon receiving the results of the invocation of the authentication hook, Slight then sends out another, "action" hook, with the user object that has resulted from the authentication process. The Slight blog entry module at this point says "aha! I see that there is an authenticated user here" (this user having been provided by the Slight Second Life authentication module) "and that the command is to add a blog entry. I will do such a thing, and, if it works, send them back a message saying that it has been posted, and giving them the URL of the new entry".
Slight takes the results of what has happened after the action hook invocation, and passes anything appropriate back to the requester. This might be highly technical data for use by a script, or it might (in this case) be a simple message to be sent to the owner via llOwnerSay or some such. Whatever it is, it sends it back. The LSL blogging widget script takes this response and, here, sends the confirmation to the resident, who no doubt proceeds directly to the page concerned to see which words they have misspelled.
This sounds like a rather involved process but in practice, the time required would be tiny fractions of a second for all.
As a note, Slight would not be simply of use for Second Life. Since it would be simply receiving GET parameters and sending a plain text response, it could be used by any system.
One significant use that I believe would be very handy is for use in Opensim, which currently (as far as I am aware) has no particular permission system set up. Upon login, the Opensim server itself could request the current role of an account linked to an avatar from a Drupal system, for use in determining whether that avatar could enter parcels or regions or change settings or whatnot. Changing an avatar's access would then be as simple as ticking a few boxes in a form that was produced by the appropriate module. This is in fact something which I hope to implement in practice, and as soon as such as thing is ready, I shall mention it on the appropriate site. (To be fair, if I have been working on things in Company Time, details of them really should appear on Company Blogs, though Slight as I envisage it will certainly be open source and so on.)
I would be interested to read any Comments or Criticisms that anyone might have regarding this Proposed Framework, so please, if you have any, by all means leave them here. I shall post here once I have the actual Code for the system in any Working State, which should not take very long to do.
