New port..

[Ian Lowe]

The IANA assigned Port is 3865, and a considerable amount of development
has
gone into the applications and development frameworks now available on our
various sites.

On a first glance, it might appear that we are standing still, as the
application list is very similar to previously... that's not, however, the
case!

Inside the heart of these xPL apps lies an elegant, robust, and very, very
useful configuration process.

Almost every xPL application has been converted to use the xPL
Configuration
Process, with the rest to follow. xPL applications initially join the
network with an instance of "default", and announce their
presence with a
special heartbeat of the "config" class:

Here's an example, from a little application that I put together to mute
the
audio sources in the office.

xpl-stat
{
hop=1
source=wmute-mutetool.default
target=*
}
config.app
{
interval=5
port=50002
remote-ip=192.168.1.65
}

At this point, the xPLHal Server spots the new application. It will check
whether it already holds a configuration for this device, and if so, will
send the device it's configuration. If it doesn't (as in this example), the
xPLHal Server will ask the device for it's list of configurable items.

xpl-stat
{
hop=1
source=wmute-mutetool.default
target=*
}
config.list
{
RECONF=NEWCONF
OPTION=INTERVAL
OPTION=GROUP[16]
OPTION=FILTER[16]
RECONF=SOURCE1
RECONF=SOURCE2
OPTION=LABEL1
OPTION=LABEL2
}

This tells the xPL Server what items are availabe for configuration.
Newconf, Interval, Group and Filter are built in configuration options,
which are handled automatically by the xPL OCX Control and the .NET DLL
available from the xPL site.

There are Three types of Configuration Items:

CONFIG, is required before the application will begin normal operation, and
cannot be changed whilst the app is running
RECONF, is a configuration option which can be changed whilst the
application is running and
OPTION is an item that can provide extra info to a device, but isn't
actually required for it to work properly

The device has some RECONF elements, and will therefore not begin operation
until it is configured by the Home Automator. Launching the xPLHal Manager
from any client PC on the network, or using the xPLHal Web Manager (from an
IIS Web Server) allows the Home Automator to list "xPL Devices
awaiting
Configuration", where

"wmute-mutetool.default"

is listed. Double Clicking on the device in the Manager brings up a
configuration window, allowing the various elements to be configured. In
This example, I have configured the MuteTool to control the speakers in my
office.

xpl-cmnd
{
hop=1
source=xpl-xplhal.turing
target=WMUTE-MUTETOOL.DEFAULT
}
config.response
{
newconf=kepler
source1=wmute-sndvol32.kepler
source2=wmute-sndvol32.babbage
label1=Ian
label2=Jenni
}

At this point, the xPL application sets the various config variable
internally, and begins normal operation. To inform the network of it's new
status, it begins sending normal heartbeats:

xpl-stat
{
hop=1
source=wmute-mutetool.kepler
target=*
}
hbeat.app
{
interval=5
port=50002
remote-ip=192.168.1.65
}

Using the configuration process is incredibly simple for any developer,
whether they are using the ActiveX OCX, .NET DLL, or Linux framework.

At this point, it's probably best if any new applications use the existing
framework, as these have been tested under some pretty severe conditions to
find potential bugs (and a considerable number of the gremlins have been
fixed, patched and eradicated!)

I would further suggest that anyone looking to port xPL to a new platform
contact us first! xPL is Open Source, and as such, people are free to hack
and slash, but at this point, ensuring compatibility and a good user
experience is probably more important than carving out swathes of new
territory!

Happy xPLing!

Ian.