Re: xAP newbie - HA oldie!

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Adam Stevens wrote:

>
>I've recently "discovered" the xAP protocol,
>
Hi Adam,  welcome !    Nice website.

> and although I'm in the
>process of testing a few of my home grown applications for general
>release, I get the feeling that in some cases I'm reinventing the
wheel,
>where thanks to some of the existing xAP modules, this doesn't have to
>be the case.  A case in point is Meteor caller ID, and SAPI (text to
>voice).
>
>
>
xAP's real intent is to provide a common basis for the exchange of
data between nearly any kind of device. As it is simple (human readable)
yet powerful it can be adopted on almost any level the designer wishes
from callerID to whole house lighting, heating, databases ,  music
libraries and more.  Another strength is that it allows a pool of
'connectors' to be built up that can be used by anyone so the library of
devices supported expands significantly. (to help avoid just what you're
saying above re duplication of effort).     When xAP was added to
HomeSeer for example every device that had a HomeSeer plugin (and
there's a lot) became a xAP enabled device - and conversley all the xAP
devices became HomeSeer devices.

>For example, currently, I have an application which reads and decodes
>Meteor CID information, announces via SAPI, logs to a DB, and
broadcasts
>CID information over UDP, which is then picked up by an number of
>"client" programs running on PC's.  It looks to me like most
of this can
>already be achieved with various xAP tools.
>
>
Yes, you chose most of the areas there that also have xAP connectors :-)
but that's to be expected because those are great targets for
automation.  So you might find using the xAP modules is a nice alternate
path or adapting any modules you have to add xAP support will add to the
library of things xAP can offer. It may be that your applications offer
different featuresets (or OS base) to those that are already available.
xAP grows generally by developers adding a device that they own to the
pool of devices so it's great to have new people on board.

>Therefore, I'm wondering if it's better to bin my work, and make the
>move over to integrating it with xAP.  Rather than worrying about
>decoding Meteor CID information for example, I could concentrate on
>Sipura CID (network VoIP device).  If this also broadcast via xAP, then
>I guess it would be compatible with the xAP Desktop, or any of the
other
>xAP modules.
>
>
>
Another alternative is enhancing your apps to include xAP ?

Yes I saw your post Adam a few days back and thought 'well there's an
unfortunate overlap with what we're doing' , but I noticed the Sipura
stuff and it would be really great to have that suppported in xAP and
xAP SwitchBoard - so I think that's a great idea.     Several
possibilities here of how to best do this either by implementing the
telephony schema in a new xAP app directly supporting the Sipura, or
using some of the schema support already in xAPTel and picking up the
Sipura stuff either directly (UDP) or via xAP - or even supporting such
things in say xAP Switchboard directly.   I am working on a CTI schema
(rather than the existing CID schema) so we should confer here.

What environment are you programming in Adam ?

>I could also change my client program to receive xAP, rather than (as
it
>does at the moment), use it's own "protocol" for
communication.  Am I
>correcting in thinking that the "standard" xAP port is 3639?
>
>
I think that's an interesting path for you as it keeps your
interoerability with your existing applications allowing migration and
you could  even add some xAP support in your server (issuing xAP OSD
messages perhaps) ? One of the goals of xAP was to try and do away with
servers as a single point of interaction as then you lose resilience,
hence the use of UDP.

Yes, xAP uses port 3639 as the send broadcast port but (of necessity)
xAP applications need to be able to listen on any port. This is because
only one application can listen on any given port on a PC . So we use
xAP 'hubs' that are the first xAP applications launched on a PC. These
acquire port 3639 and then relay the incoming xAP brodcasts onto any
other xAP applications running on the PC. This is actually fairly
transparent to the applications. xAP applications can acquire any port
at launch and they announce in their heartbeat which port they are
listening on.  The hub sees this and obligingly forwards the xAP traffic
to them.  Any application can send xAP packets directly of course to
port 3639.

xap-hbeat
{
v=12
hop=1
uid=FF108900
class=xap-hbeat.alive
source=KCSoft.Viewer.Lightning
interval=60
port=52000    <<< here you see this application is in fact using
port 52000 to receive
pid=3436
}

>What's the drill with "releasing" xAP software?  I can host
the stuff
>myself, but it there a procedure to get it listed on the xAP web site?
>
>
You are able to submit news stories to the main xAP site and you can
provide links to your apps from there. We have long debated having a
central repository of all xAP applications but in practice most people
seem to want to host them locally on their own xAP sites. This list is
good for announcing things too.    We should make more of an effort to
have a master list somewhere I know.  The xAP Automation site tries hard
to do this and there is the xAP Wiki as well of course.

You will need a xAP 'vendor id' which is the first part of a xAP source
address - and it will remain unique to you.  4 - 16 characters IIRC -
just choose one (FIRS ?)  and ask on the xAP Developer Yahoo group for
it to be issued.

If you haven't found the xAP v1.2  spec it is available on the main xAP
website at www.xapautomation.org and also do take a look at the BSC
(Basic Status and Control) schema there as it is a great way of getting
immediate interoperability between xAP devices and plug and play with
HomeSeer., Xlobby etc.  BSC as the name implies handles simple devices
that are of three types,  either 'ONOFF' ,  LEVEL based or TEXT which
conveniently encompasses 99% of all devices.


Any Q's just ask away - looking forward to getting you onboard.

Kevin