Re: More questions......

[James <james@xxxxxxx>]

turner228 wrote:

>Well I have some more questions after reading various specs and so
>on (again):-
>
>The specification says taliking about a source address
>"The <vendor> field is assigned to the device developer by
the xAP
>group"
>So If I were to write a connector program to interface with some
>external device, say using VB and the OCX (from Patrick Lidstones
>site I think (which appears to be down at the moment)) Would someone
>here have to agree the vendor ID with me?
>
>
Yes each developer/company needs a unique vendor ID. Some current
examples are mi4, kcsoft, rocket, scentium. Just let us know a name you
would like to use (8 alphanumeric characters or less).

>The specification also talks about Target addressing. Thinking about
>the desktop, is this supported for the different displays on a
>desktop, or will it be?
>
>
Desktop is mainly a listener. It will receive and process messages
targeted to mi4.desktop.pcname (and wildcards there of) or messages with
no targets. This part of desktop is used to fill up all the data in the
xAPVars of all the displays. However there is another way to control
desktop. You can target a specific display with a display.control class
to mi4.desktop.pcname:display01 . An example would be

xap-header
{
v=12
hop=1
uid=FF123400
class=display.control
source=mi4.test.rig
target=mi4.desktop.laptop:display05
}
control
{
label01=Hello
}

would cause label 1 on display 5 on the pc called laptop to change to Hello
Future releases of desktop will have more targeting options.

>I am a little confused about the schema. I have seen examples in the
>specification and elsewhere, eg
>class=mail.notification
>class=Thermostat.status
>class=CID.notification
>class=cid.lookup
>
>Which don't seem to be supported by published schema. Are they valid
>schemas or just examples?
>
>
Anyone is free to make up any schema they want as long as they stay
within the rules of the xAP spec and have different class names to
existing ones. The only thing that you can't do is have a class that
starts "xAP" as these are reserved for official xAP schemas ,like
the
BSC one.
Schemas should be published somewhere as it makes life much easier for
every one. The wiki  or on this list is a good place to start. It is
often a good idea to post the proposed schema to the developer list
before going too far with it just incase there are any ideas/errors in it.

>Are the schema fixed, can they be modified and new ones created?
>
ish,no,yes
Schemas once published shouldn't be changed as this would break existing
apps. However you could add to a  schema either by additional item value
pairs or additional blocks. My weather schema is a good example. When
first published it had every possible entry in it for weather info that
was needed, however Michael later found he needed more options which his
app needed so he added them and informed to the list that he had done.
The important thing was that all existing elements remained unchanged.
Later still when I needed to add time of day info to the schema I added
them as an extra block, again no changes to existing elements so no
compatibility problems. If i even needed to radically change the schema
I would uses a totally different class name to stop any problems
occurring. Keeping all the changes documented is always a problem,
hopefully this is where the wiki will come in as it makes the updates
much easier to share.

>
>For instance I have a couple of LCD devices which have 8 rows by 24
>characters. This could not be supported by the display.text schema
>because it only allows 5 lines. So could I create a display.biglcd
>schema based on that of display.text?
>
>
Just use display.text and inform the list that you are using some more
fields, easy as that. Remember in this case and in the weather one above
all the extra fields are optional ones so no compatibility problems will
occur.

Things to keep in mind above and beyond what is in the spec document.
xAP schema should be human readable which means using descriptive names
for things however xAP is also a lite protocol  so names should be clear
and concise.
Dates should either be YYYYMMDDHHMMSS or YYYYMMDD format - stops
international problems
Using multiple blocks instead of one huge one is often clearer and simpler.
Always a good idea to post the schema to the list before programming any
thing with it, just in case there is a problem.
If a schema is well defined then pulling out a single element of data
should be as simple as asking for S:C:S:I  as in Source Class Section
Item . If you find that you need to ask for SCSI when this bit equals
pir4 and room=hall and ...  then the schema needs a re-think - eg

Source=mi4.alarm.house
class=alarm.goneoff
}
Alarm
{
sensor=pir4
state=triggered
room=hall
}
nice looking but fiddly to extract

source=mi4.alarm.house:hall.pir4
class=alarm.goneoff
}
Alarm
{
state=triggered
}
much better much simpler better hierarchy  same data.



Hope this all makes sense, any questions just ask

James