Re: Re: MusicLobby Users?

["John B" <home-automation@xxxxxxx>]

----- Original Message -----
From: "Ian Lowe" <ian@xxxxxxx>
> ----- Original Message -----
> From: "mark_harrison_uk2" <mph@xxxxxxx>
> >
> > You know, we REALLY need to work out whether xAP and xPL can come
> > together, and if they can't look at ways of bridging between
them.
> >
> > The biggest technical barrier was the use of the xAP IANA port by
> > xAP. But now your IANA application has gone through (well done!),
> > we've got an easy solution for that.
>
> With you, right to here.
> xPL and xAP can now co-exist on a network, a change that gave us a
> considerable amount of work. This opens the door for many things,
including
> simple bridging of messages between environments where it's desired by
the
> end user.
>
> There are technical challenges in the sheer amount of data that can
exist in
> a xAP message which would not appear on the xPL network, and
conversely, the
> additional fields that would have to built up from an xPL message to
make
> sense in a xAP environment, but these are not insurmountable.
<snip>
> > Interested in collaborating?

While I agree with everything Ian has said, I would like to add a few
points:
I was not involved in the development of either xAP or xPL, and have never
been involved (nor interested) in any of the politics between the two
camps.

I looked at both protocols as an outsider, and I made my choice, based on a
set of criteria that best fitted my own needs.

As a developer, I prefer xPL, and the professional and dedicated approach
of the other members of the xPL development team has amazed me over the
last few months.

However, I feel we need to take a few steps back and look at the original
design goals of xAP and xPL.
If we are to truly simplify the integration of home automation devices,
then it is just silly not to try and work together.

Looking at things as an end-user, and not a software engineer, I really
don't care whether it's xPL or xAP... all I care is that one device can
talk to another, and surely it's the end-users who we should be thinking
about.

xPLHal is an excellent central controller (IMO of course!) and I think
there would be a great benefit in attempting to support both xAP and xPL.

I see no reason why, for example, an xAP-based Meteor unit couldn't send
out a xAP message containing the CID info, which could be picked up by
xPLHal, which could then send out an xPL message to announce it, and an xPL
OSD message to display it on Tivo.

Likewise, an xPL message could be picked up by xPLHal, and translated into
a xAP message to be received by xAP devices.

As Mark says, xAP has support for hardware that xPL doesn't yet have, and
likewise xPL has support for some devices that xAP doesn't yet.

I don't think we'd be helping anybody if we didn't at least attempt to
develop some sort of a bridging mechanism, and xPLHal is probably the best
place for such a bridge.

xPL will always be my protocol of choice, but I don't see why that should
stop me from using, or interfacing to, xAP devices.

If someone develops a xAP application or piece of hardware, then it would
be silly for me to turn it down purely on the grounds that I disagree with
some of the technicalities of the protocol.
And I'm sure the xAP guys wouldn't want to have to xAP-enable something if
it was already xPL-enabled, if a simple bridge could join the two worlds
together.

Right.... I'm off to run away now before Ian reads this ;-)

Regards,

John