[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: xAP slimserver Connector, Homeseer, HS xAP plugin
- Subject: Re: xAP slimserver Connector, Homeseer, HS xAP
plugin
- From: "Kevin Hawkins" <lists@xxxxxxxxxxxxxxxxx>
- Date: Sat, 08 Jul 2006 09:53:24 -0000
--- In xap_automation@xxxxxxx, Lehane Kellett <lehane@...>
wrote:
>
> Yes,
> I've seen the same.
>
> It makes me wonder whether native xAP support in the Slimserver is the
> way forward (as xPL). I did add some code to the xPL module for my own
> use a while back, when I was using xPL, for some alarm and power
events
> - I didn't submit them to the nightlies though.
I did the same - I have an adaption of the xPL perl code that talks
xAP instead but the reality is that the xPL code offers very little
feature support for SlimServer . The xAP connector offers far more
including the most useful (multiplayer, prioritised) display queing
which I find invaluable. Also SlimDevices would prefer the xPL code
(or should I say any future similar versions eg xAP) implemented as a
plugin and not as core code
I am in two minds about the integrated vs standalone/CLI advantages....
Implementing a plugin requires a very good understanding of the
SlimServer code base and that is a constantly moving target with daily
updates - I have seen more than a few such authors give up in the end
and maintain compatability only with certain older versions. It means
coding some quite involved stuff in Perl in an open source project and
also places more processing onto SlimServer which struggles at the
moment to provide adequate performance.
The CLI has been honed quite a bit recently and offers very powerful
chunk based library searches - really to enhance integration with
external controllers eg AMX and Crestron, this makes it well suited to
the xAP media schema. Also it's now of a maturity that you can moan at
the developers should it break or change which eases maintainance.
However this makes setup more complex, introduces platform dependence
(in the xAP connector code)and also means another layer in the
implementation.
Overall I'm slightly siding on the CLI as the most viable approach,
particularly because of the display queue management and some exiting
code to work from. I wonder if Stuart might be able to provide the
source code for the SlimServer conduit - would you (or anyone)
familiar with C# be able to give this a once over to see if we can
firstly fix the reported issue with stability and response, and
secondly I would have a look at the CLI issues. I can adapt the CLI
code without too much problem although as I dont know C# I might need
some help in the syntax area.
At one time I also was talking to Stuart about breaking out the queue
management portion into a standalone xAP network function. This type
of intelligent multi destination, multi priority , timed queue has
many applications in HA and could be a useful standard xAP message
queue feature , not just limited to display messages ... if that could
be done then the internal/external Slimserver conduit debate would be
different again.
Kevin
>
xAP_Automation Main Index |
xAP_Automation Thread Index |
xAP_Automation Home |
Archives Home
|