just to be sure we're in sync... you know that all Pluto devices communicate over a socket, so although our DCE library is in C++, any device could be written in any language so long as it uses the same protocol. All the logic of Pluto is handled by devices which are exchangeable/hot-swappable. DCE router is nothing but a message router--it has absolutely zero logic in it other than passing a message from one device to another. so DCERouter imposes no restrictions--any device that all can register and start processing messages like commands and events. DCERouter also supports a message interceptor mechanism. This is where a device can pass in a criteria and say I want to be notified of all messages that meet this criteria.
for example, the media plug-in device registers that it once to receive all messages of command=abort ripping or event=ripping progress, because it always wants to know what ripping jobs are going on and have been completed, since it maintains all the attributes for media and needs to update the database. This means any time any device, such as an orbiter, sends an 'abort ripping' command to the disk drive device, which handles ripping, media plug-in will be notified and get a copy of that message.
all the logic of handling and responding to events is handled by the event plug-in device, which registers a message interceptor of all messages where the type=Event (ie any event). event plug-in looks in the Pluto main database in the table EventHandler to see if the user registered a handler for that type of event. If it finds one, then it evaluates the criteria in the table Criteria to see if it's a match. If it does, it executes the commands in the given command group. so it's a very primitive and simple event handler that does not allow for complex calculations because the intention was a point-and-click for mainstream users.
when I talked about adding a ruby based event handler, this would just be another device that also intercepted all messages of type event, but instead of a valuating them by comparison to a database table, it would execute a snippet of Ruby code. this would be very trivial to do because we already got the C++/ruby interaction working for our GSD, and it already hands-off incoming messages to ruby snippets. so all we would need to do is creating another GSD that did the same thing for events instead of commands. It would be a fairly trivial thing.
you could do the exact same thing in Perl right now with no changes to the framework. You would not even need the C++ interaction. If you open a socket connection to DCE router on port 3450, send a properly formed message interceptor message, then DCE router will give you all of the messages you want to intercept, such as events, and you can do whatever you want with them, including firing commands based on criteria from configuration files, databases, what ever.
so on to your specific example:
>>1) You open up so that a larger group of developers can create scripts
I understand about a developer creating an X10 alarm system, but what specifically would you need us to "open up"? I'm not sure I understood what you meant by that, or if we have done anything closed to that would prevent a developer from doing what he wanted.
>>2) Pluto integrates the Perl codebase into its OS layer...
I'm a bit fuzzy on what you mean by the OS layer. Pluto does not really have any hooks into the OS other than just standard socket code. For example, I run Pluto on Windows just because I am more comfortable in the Visual Studio development environment. All of Pluto's code runs just fine. of course the media players (Xine/Myth) are Linux specific. so I have a Linux media directorthat I change the ip address in the pluto.conf to points to my Windows-based core. so when you say "integrates the Perl codebase into its OS layer", can you clarify what you mean? to my knowledge all you would need to do is add Perl. our dependencies are also database driven. In your Pluto admin site if you choose a device templates, you'll see there is a pulldown for the package. And in advanced, packages you see the package definitions including all the dependencies dependencies. all of Pluto's packages are built automatically by an unattended build system. So you could create a device template for a Perl device,add a package for your device in advance, packages, specify under the file listing what files you want included, and add under the dependencies section Perl. Perl is still included in our mirror--it's just that nothing depends on it. But if you added such a device, without changing anything, Perl would get installed on your device would run. In fact our startup scripts don't care what language the devices written in, your Perl device would get started just like all the other devices. So I'm not clear what we would need to do for this point.
>>3) Pluto integrates the scripts into its GUI
Our GUI (Orbiter) actually has no scripts. In fact there is virtually no logic in the GUI for specific applications. For example there is absolutely nothing in orbiter relating to lighting, events, security, telecom, etc.. The look and feel andfunctionality of the telecom screenis defined in the database: DesignObj tables. we use a Windows C# program called Designer to build the screens and specify what commands are attached to the buttons. But none of this requires any code whatsoever in the GUI Orbiter. so I don't think any changes to orbiter would be needed. You could create new screens in the database using Designer that did something you wanted for X10. There's a table DeviceTemplate_DesignObj which provides the link that says what's devices use what screens. It is completely free-form and unrestricted. I could create a screen (ie DesignObj) for a new device template (Jandy pool control) that had buttons for maintaining a swimming pool. without touching the code, that new screen would appear on all the media directors, PDAs, mobile phones, etc. whenever you wanted to control your swimming pool.
>>4) Pluto creates a new GUI layer for the alarm system
our designer program (ie what the developer uses to build the database records defining the gui/look/feel) does suck. however, it is usable and not terribly complicated--the only thing is you need Windows. since the user interfaces database driven, our sqlCVS utility will automatically synchronize. So if you ran designer, and created a new screen, and then in Pluto admin did a Advanced, sqlCVS, checkin, and checked in the "designer" repository, your new screen would be synchronized with our main server. you will be given a batch number by sqlCVS. all sqlCVS commits (even infrared codes) go into a quarantine state so we can review it before it hits the release. but if you send us an e-mail and say "please approve batch 89775", for example, our tester would go into his local machine, enter a command to merge that batch into his test machine, confirmed that it was okay and didn't break anything, and then approve it and it would be part of our next release. so the developers are not really tied to Pluto for the GUI.
does that help? we don't have any Perl programmers, but I know Pluto's framework very well. So if there is a Perl programmer who wants to take this on, we could also do a phone call for brainstorming how best to do it.