RE: Topic 1: Base Level Status Schema

[Kevin Hawkins]

Ha- overlapped emails again - the wonders of half duplex conversations -.-

> -----Original Message-----
> From: <a
href="/group/xAP_developer/post?postID=r82DTv2Ytd2Vsd62uPw4ij3I4rg4eKPwr5zjF_9EC47BbsSa91FTdLC3mL--5dOhVQUnkhx4Eqg">i.bird@t...</a>
> Sent: 02 September 2003 11:15
> To: <a
href="/group/xAP_developer/post?postID=8r7JLk6oOH3SL3tjHH8ZUoeKqOCKKjeDdPfmCd3UhGVsvO6haYG-0DXQvzMJPobBkn7y3WNGcfCnGdKAQ-qqYVmX_7i1Lg">xAP_developer@xxxxxxx</a>
> Subject: RE: [xAP_developer] Topic 1: Base Level Status Schema

> > The jury is out here on these but I would like to see it as a
> schema in
> > its
> > own right which the developer can choose to support or not.
>
> >This I see as a problem - what I am advocating here is a mechanism
to
> allow
> >xAP devices to inter operate in a basic fashion and to have a very
> basic
> >form of discovery of the inputs and outputs a device has, and
their
> >capability eg ONOFFLEVEL - if developers chose not to support it
> then we
>
> Erm, wrong end of the stick a little here. I was thinking of two of my
> projects with this. The current I/O controller would support it for
the
> reasons you give. I am also thinking about a display device which
would
> simply show menus and return menu options etc. No input or output so
no
> need to support the current basic schema as we are talking about it so
> far.
> I did not mean I have an I/O board and I am going to ignore the Basic
> schema and go my own way. Sorry, bad wording on my part.

Great - I'm going to have to change my stuff too - but I am at that stage
now when I need to finalise my schemas and get something out there. I would
hate to think we fudged the issue to meet deadlines or because of wanting
to
preserve already coded routines. Lets thrash the actual thing out so that
we
have the same understanding - of course P's views could be very different..

>
> >What can I do to convince you of
> >the need to do this, and how simple it is - and what exactly is
the
> area of
> >concern in the implementation ?
>
> No problems here as I hope above explains. The simplicity bit we are
> working on and time will tell but there are no major problems I can
see
> at
> the moment. I think a phone call between us would help me at this
point
> in
> the development cycle. If that is OK let me know off list and we can
> arrange a time and numbers.

I am actually in all tonight if you want - you have my # I think ?? Or I
can
call you, once your family tasks are out the way.

>
> One of my older areas of concern was the code space required to
> implement
> all this. As an example my I/O board has gone from a 2K PIC to an 8K
> PIC
> and I now on a 32K Atmel chip and at 35% code space used.

Nah - 65% still free - the optimists view

This has
> pushed
> up the price of any hardware by at least 10 quid on chip cost only. I
> don't
> have a problem with this as I love the new development environment and
> am
> pleased with the way xAP is going but it has moved the bottom line
> hardware
> requirements slightly. Again I don't have a problem with this as I
> think it
> is the best thing all round at the moment.

I think it's a good choice to get it right at the cost of £10 rather than
restrict the implementation. PLUS having that extra codespace gives you
headroom in development that saves loads of time - lazy I know but works
for
me.

>
> I have also had a little feedback from a couple of guys who want to
use
> my
> board but are doubting their ability to do the programming needed.
> Because
> of this interest it would be great to get this sorted sooner rather
> than
> later (this is NOT a nag) and then I can help them.

I agree - I have the same time pressures now.


My current thinking are defined xAP.inputs and xAP.outputs message
body sections that are bodies that you would need to support within say
IanB.status and IanB.control - if we can standardise on just the message
body part and you allow for recognition of 'xAP.status' and 'xAP.control'
classes each of which utilise the xAP.inputs and xAP.outputs body parts do
we have all we need ?? I am still undecided on multiple bodies or
named/indexed subs.

NB I am using xAP. naming here to try and convey the standardisation
of the body parts and schemas - of course this would later require approval
for use.

I am also skirting around a sort of inheritance issue here - [ which
is another topic(2) and a previous thread "Class Inheritance" ]-
really what
I am saying is that your own status schema should inherit these bodies as
mandatory inclusions in whatever you did. However we need someway of
showing
this inheritance in the class naming for it to be workable automagically.

Class=xAP.status.IanB and xAP.control.IanB perhaps where IanB is a
superset of xAP.status and therefore Homeseer etc know that they can get
status, and control the device using xAP.status and xAP.control with pre
defined body sections. It's just that the dot hierarchy is sort of inverted
here :-( isn't it ? Programmers comment invited !

K