RE: Pluto

["UKHA" <ukha@xxxxxxxxxxxxxxxxxxxxxxx>]

On 29/01/2006 at 20:44 Ian Lowe wrote:

>> ahhh that's better...
>
>Indeed. Burns barely makes sense to a native speaker. ;)

:)


>I think you are being rather harsh - we have produced a set of tools
which
>can *very* easily tie together the various HA systems. The ease of use
>elements are coming, but progress is slow - and that's the whole
discussion
>again...

>The problem from day one has been getting people to test the stuff in
>anger. Recently we had a bunch of work throughs on the xPL forums -
debugging an
>install as a new user hit problems.
>
>The value of even a couple of people willing to describe their own
>environment and live through a series of bug fixes is incredible - you
can
>see the tools improve over a series of days rather than weeks or
months.
>
>In the course of the xPL Project we have had maybe four or five people
>*ever* extend us this help. It's nigh on impossible to produce rounded
user
>friendly tools in that environment.
>
>*but* we are still trying to build in ease of use - the determinator
system
>which means that people who don't know how to script can build useful
>environments is one example.
>
>Ages have been spent trying to get together the building blocks for
>friendly
>user tools, things like xml descriptions of what messages do which
provide
>no real benefit to the low level guys, but will help with cross plaform
>tools..
>
>Thing is... Who wants to spend time at night building software when
it's so
>hard to get people to even test it?
>
>Pluto is a business, we are all hobbyists doing this in our spare time.


Sorry to reduce everything you said donw to this one... but yes pluto is a
business
and we are hobbyists - but that's why we end up with the problems you
describe.

It's because we do this stuff in our spare time that it takes so long to do
and test.
i'd venture that most people on the xpl list is are developers either of
hardware or software
and thus need their own stuff testing - while I'm fairly happy to turn my
house into a test bed
for some technologies I still have to maintain the basic functionality.

I pointed at pluto because I felt that it would actually be of use to both
developers and users.
Developing an interface to everything in you house it not an easy thing to
do, particularly
if manufacturers have or show little interest in xpl (or xap). Pluto seems
to pull it all together..

isn't that the ultimate goal?

Don't take this the wrong way - but xpl (or xap) doesn't solve all the
problems, sometimes you need
to have for example a specialist doodad using a different protocol to get
the result you want - shouldn't
we accept that and integrate where possible - and if some company wants to
do that for us let them?



>> Well, Xap is a 'fat' protocol, xpl is slim - isn;t that one of the
>reasons xpl was born? You also seem to believe xpl being a 'bastard
child' is a bad thing. I
>don't.
>
>In context, you weren't exactly being flattering ;)

ok, but it wasn't an insult. I did in fact consider it before sending it
and
actually thought that if I'd said "and the child it spawned"
would be an
insult - as I understand it there is a little tension between the xap and
xpl
camps. the 'bastard child' was meant to indicate some distance between
the two. Perhaps it didn't read as it sounded in my head.

>That being said - engage with us! Seriously.
>
>One of the things Pluto seems to do is abstract the various devices out
>into a database - homeautomator used a similar abstraction process, and
the idea
>of database stored displays.

I always believed that homeautomator (ehome hvc)  had the right idea,
simply because
the interface was pretty much configurable for and display device but the
backend just
stayed the same and did it's job. There were drawbacks, looking back now I
should have
built the hvc part to accept plugins and thus i/o from other devices. It
was my mistake and
knowing what I do now, if I had the time again, that's what I'd do. The
fact that I feel stupid
for not doing it in the first place is another irritation I have to live
with.

If I attacked the problem again I'd do a number of things - which I'm doing
to list here :)

1. It'd run under linux. Although it would be nice to make it platform
independant I'd
want to concentrate on a standalone box that I could power on and more or
less forget
it existed. Let's not get into the windows stability argument. It also
means an embedded
system - Look at the WRAP boards for example - a small and cheap platform
for a controller.
( http://tinyurl.com/bq3ns )

2. It's be redundant - If I wanted to be sure my house was working I'd have
2 boxes running
and the secondary one would take over if the first stopped responding.
Boards like the WRAP
come in at a price that makes the redundany an attainable goal. This would
be a relatively simple
implementation - The master does all the work, but also tells the slave
what is going on. The slave
keeps track (as does the master) of what's going on but only actions
requests if the master disappears.
This means that if I turn a light on then both boxes are aware of it - if
the master fails the slave still knows
what state everything is in so there is no loss of fluidity in your home.


3. It'd be open source. Not because I'm and open source zealot or a really
nice bloke but simply
because if it's open source then we don;t have to reinvent the wheel - we
can make use of all the
work done by others. Let's make things easier for ourselves.

4. Plugins plugins plugins.... everything would be a plugin -  the core
would run but do very little other
than pass data to/from plugins. This allows us to build a solid core that
can withstand plugin developer
mistakes so that the whole system continues to run - maybe the core even
has the power to kill bad plugins
to ensure the running or the rest of the system (debateable).

5. Plugins go through a no cost* certification process to ensure they don;t
break things badly - they are then offered
as part of the system downloaded from the main site not from individual
developer sites (another bugbear) perhaps via
the interface to the system itself. In other words, certify your plugin as
ok and users know it works ok and is safe to use.


>It's probably not a massive leap of logic for us to say that we also
have
>been looking at abstracted displays, whether that's an html page, a
little
>application, and applet running on a PDA, whatever. Way back when, I
hoped
>that xPL being added into home automator would provide that interface.
>
>As you know, it didn't happen - then. How about now?

Errm, well actually it did - sort of... it didn't make it to production but
it is in the version
I run - partially.

Andy