Re: Re: MusicLobby Users?

["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. The problem
comes next:

> xPL is a subset of xAP, which adds an enforced policy layer embedded
> in the protocol rather than abstracted out and some parsing-
> efficiency changes to the header.
>
> We both know that it's really the poliy layer that separates us. We
> agree that it adds value. We agree that it imposes limitations. Our
> difference is whether the value justifies the limitations :-)

Actually, we don't agree on this at all, and therein lies the problem.

It has been asserted, and you have repeated here, that "xPL is a
subset of
xAP" and  "xPL is a policy layer".
None of the xPL developers agree with those statements. As you said to John
B two days ago, "I would be grateful if you could NOT present
mis-information about xPL".

Seriously though, xPL contains several elements that do not exist in xAP
(and vice versa), and calling it a "subset" is not helpful to
anyone. xPL
should be correctly regarded as a fork from the original xAP project. xAP
v1.2 took one path from the v0.9 protocol, xPL took another. The
differences
are more than skin deep.

> Interested in collaborating?

Thanks for the offer, but I fear there is just too much baggage involved.
There are still serious ongoing discussions about the nature of xAP
configuration, sub-instancing, UIDs, or even Point to Point
acknowledgement,
and that's a bunch of discussions that I for one can't spare the time to be
involved in again.

xPL as it stands is finished, completed. There will be no changes to the
core protocol from here on in, as whilst it may not be perfect, it does
everything we need it do, perfectly well.

It's been quite good today, discussing the possibilities of using xPL in
UKHA_d again, without fear of it turning into a tit-for-tat with xAP.  The
xPL developers would rather just get our heads down and produce software
tools that do cool stuff in an HA environment... I'm sure the xAP
developers
feel the same, and I'm certain that UKHAers in general are bored to tears
with xAP/xPL debates, so let's concentrate on just getting the job done...

Ian.