RE: Re: Context parameters within Message Bodies

[Kevin Hawkins]

> -----Original Message-----
> From: mark_harrison_uk2 [mailto:<a
href="/group/xAP_developer/post?postID=lwqgS8Z1QSASBAuzzXZJv69gAML_jQy_mj7lKimgN-ocokkNxXBmOoJ4OiKyn5X_pj-OyocdQ10n4GuFgQ">mph@a...</a>]
> Sent: 30 November 2003 11:43
> To: <a
href="/group/xAP_developer/post?postID=xP5HmykwvACT9JsRGFG8a5DGrEzd5k2RDpRX60E--t6GIy6YaO_BJ4va8t4XQ9kS6ZI8XdTjOJ_iIlC_2DW0es5yRd8b">xAP_developer@xxxxxxx</a>
> Subject: [xAP_developer] Re: Context parameters within
> Message Bodies
>
> Kevin,
>
> The key point to me is the phrase "if a human reads it".

Which is partly why I added the last example as it is not clear even to a
human ! To have to interpret schema nuances automatically (programatically)
is quite awkward, and will prove frustrating to many less technical users
trying out new xAPp's and devices. However alongside this I agree that it
allows everything to be flexible, (almost freeform) which is a xAP tenet.

>
> xAP is sophisticated - it is not a "plug and play" where
> new devices can simply be added and the rest of the house
> will in some way know how to respond.

Basic status and control does provide this functionality - that was the
purpose of defining it.

>
> A xAP installation requires an INSTALLER. Whether this
> will be a professional installer or a hobbyist is irrelevant.
>
> It is part of the role of that installer to understand the
> classes/schemas that will exist, and ensure that their
> content is interpreted meaningfully by other devices
> within the xAP realm.

It is the problem programatically of interpreting context that adds load of
code requirements (including understanding schemas) to the applications -
this makes the code requirements for receivers and controllers very
onerous.
Consider for example a state cache controller.

>
> To facilitate this, I think that the next thing that xAP
> needs is some rules-based language (xAPScript?) to hold
> state, and then work out what needs to be done. Obviously,
> hand in hand with this is a central controller... but this
> central controller is an interim step.

Which is why this issue is coming up - establishing state programatically
is
awkward when context is within bodies. This central controller idea, and
the
discussions around 'how' is what has sparked this thread.

> In the longer term, there will be a xAPScript COMPILER
> that is able to push out the intelligence to end devices.

Really ???

> At present, these intelligent end devices don't exist, and
> the existing end devices are fairly simple... but one of
> the cornerstones of xAP is that the work WAS put into the
> 1.2 protocol design to allow massively parallel architectures.

Yes I agree (been there - got the T shirt)... but what you are saying is
that end nodes ultimately will be receiving compiled scripts (xAPscripts)
telling them how to interpret the various schemas - sort of blows the small
pic based end nodes out of the water. Where, and who is developing this
capability ?? What I'm trying to address is here and now.... (and getting
real things working practically today in the #2 mode below)

>
> For example, imagine a simple xAP installation comprising of:
>
> - A TiVo used as an output device
> - A Meteor connector
> - A POP3 connector
> - A "controller"
>
> The TiVo would display
>
> EITHER
> - nothing
> OR
> - the subject and sender of a new message OR
> - the phone number and name of a caller
>
> There are two architectural possibilities here:
>
> 1: The xAP-TiVo software decides which to display, based
> on rules encoded within in.
>
> 2: The central controller receives all the xAP messages,
> then sends out a basic "xAPdisplay message" on which the
TiVo acts.
>
> At present, number 2 is probably where most people are...

Yep - they are - but some applications do already today have their own
ability to choose which things to display for example when presented with a
choice or a conflict (the #1 approach) - a sort of priority based set of
rules. However due to the configuration and code required to do this these
are predominantly PC based applications.

Taking Tivo for example, it is unusual in that yes you can hack it's
internal code to make it have some extra cpabilities and intelligence - but
with a SliMP3 device for example you can't do this at the end node. SliMP3
displays therefore will always require a centralised controller to be used
by xAP. Even if xAP capabilities were rolled into the SliMP3 server it is
still a centralised controller. xAP has a role to embrace existing HA
devices - as well as the bespoke (tba) native xAP ones.

Kevin

>
> Regards,
>
> Mark
>
> --- In <a
href="/group/xAP_developer/post?postID=xP5HmykwvACT9JsRGFG8a5DGrEzd5k2RDpRX60E--t6GIy6YaO_BJ4va8t4XQ9kS6ZI8XdTjOJ_iIlC_2DW0es5yRd8b">xAP_developer@xxxxxxx</a>,
"Kevin Hawkins" <lists@u...>
> wrote:
> > ...
> > UID=FF122200
> > Source=ACME.TV.listings
> > }
> > showing.now.1
> > {
> > Channel=BBC1
> > Program=A Question of Sport
> > Duration=40
> > }
> > showing.now.2
> > {
> > Channel=C5
> > Program=Boxing: Fight of the week
> > Duration=65
> > }
> >
> > (I think we agreed we would index duplicate section names ??)
> >
> > Here's the snag - the "Program=" data in the first body
part
> relates to BBC1
> > and in the second body part to C5. There is a 'context'
> set by the
> > inclusion of the Channel= that relates to the other
> parameters. Now
> when a
> > human reads this it is easy to understand that Channel= sets the
> context but
> > how would a computer know - it could think duration= set the
> context. To
> > readily pick up what program is on say BBC1 now requires logic to
> be applied
> > - "Is channel=BBC1 if so then read Program= from the same
body
> section" ...
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Ink Cartridges or Refill Kits for your HP, Epson,
> Canon or Lexmark
> Printer at MyInks.com. Free s/h on orders $50 or more to
> the US &amp; Canada.
> <a href="http://www.c1tracking.com/l.asp?cid=5511";>http://www.c1tracking.com/l.asp?cid=5511</a>
> <a href="http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/dpFolB/TM";>http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/dpFolB/TM</a>
> -----------------------------------------------------------
> ----------~->
>
> To unsubscribe from this group, send an email to:
> <a
href="/group/xAP_developer/post?postID=I5QkT4_gCLjJgXImRhv2ZYG-ennVLgpqn7vDdXbLVbWujVLPz_2-2XzV0ZVEzAPj2A2Kkt0Q1d0LGCUlI6ej5U_b3BJWGw5imfHjL5OTEpc">xAP_developer-unsubscribe@xxxxxxx</a>
>
>
>
> Your use of Yahoo! Groups is subject to
> <a href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</a>
>
>