RE: Re: Meteor Caller ID drivers ?

["Chris McGookin" <chris@xxxxxxx>]

Patrick,

I've been wondering if there's a way I can convert the schema for the
Meteor to suit the other devices I have like the RS232 amp- would the
SDK let me then compile this?
I've got a working knowledge of snmp schema and other scripts of that
sort of level but that's about as extensive as my programming skills
get.

Regards,

Chris

-----Original Message-----
From: patricklidstone [mailto:patrick@xxxxxxx]
Sent: 01 May 2003 12:37
To: ukha_d@xxxxxxx
Subject: [ukha_d] Re: Meteor Caller ID drivers ?



--- In ukha_d@xxxxxxx, "Nikola Kasic" <nikola@k...> wrote:
> Patrick,
> You often refer to xAP and compare it with Autom8it.
> I thought that xAP is just a protocol, not the application.
> Or there is some application available that can handle xAP messages?
> Please enlighten me :-).

At the base level, xAP is a protocol specification. The protocol
specification is published in the public domain, but is copyright.
Anyone is free, and indeed is encouraged, to implement applications
or devices which comply with the protocol. The overall goal is to
promote inter-operability between devices; you can think of it as an
esperanto for HA if you like.

A number of people - myself included - have implemented SDKs
(software development kits) which allow xAP compliant applications to
be built quickly and easily. The terms under which these are made
available varies, but most, if not all, are free for non-commercial
use.

Then at the top level, built on the SDKs, there are a wide variety of
applications. These provide xAP connectivity for a given device or
software application. Examples include: notification of new e-mail
arriving; LCD display drivers; caller id interfaces and so on.

Because xAP is fundamentally a broadcast protocol, any xAP
device/application can potentially act on information broadcast by
any other device/application. This gives a high level of resilience -
you don't *have* to rely on a central controller, and if the central
controller breaks, the system can degrade gracefully. (Having a
central, or at least powerful, PC in the system does make sense for
stuff like web serving, and they do have a place - I just don't want
to rely on them to ensure I get up in the morning!) The esperanto
nature of xAP makes it very easy to add new devices/applications
without having to spend ages reprogramming the rest of the system to
recognise that device: as often as not, the new device "just
works".

Coming back to the central controller issue: Today, whether you use
Autom8it, Homeseer or whatever, when you add a new device you rely on
a plugin being available to support that device. There is a huge
amount of duplicate effort being expended - there are umpteen meteor
plug-ins for example - wouldn't be easier if there was
one "universal" one which was enough? If these controllers choose
to
support xAP (as Mister House has done) they then have instant access
to all current and future xAP devices, with xAP providing a kind
of "Universal plugin" architecture. For the end user that is a
pretty
compelling proposition... but it also levels the playing field
somewhat for the authors of cental controller software, and I can
understand why that is scary for them. Fortunately, most Win based
controllers provide access to VB script - and embedding for an end-
user to embed the xAP active X contol is, for the most part, straight
forward, so they don't have to rely on the controller developers
providing integral support to leverage xAP... (Although I'm sure
integral support will come with time -- and I'm looking forward to
it :-)

Patrick