RE: Multi-block message bodies

[Kevin Hawkins]

> -----Original Message-----
> From: Stuart Booth [mailto:<a
href="/group/xAP_developer/post?postID=WDw9hVOK4cLXQvDpJBK4LHLVMgdG-x9ILECqZDnEFs9SvOI7hv5bxOxg1-Ofoxdp-cntkTmPoO8Ng117KnzI1Rs">lists@x...</a>]
> Sent: 11 June 2003 11:56
> >We anticipated that multiple bodies containing very similar
> information
> >(perhaps identical) would be required and hence provisioned for
the .1
> .2 .3
> >or indeed .1.1 .1.2 or .1.a .1.b type hierarchies although I would
> hope we
> >only ever see .1 .2 .3 etc. I think this is actually the likely
> outcome as
> >udp packets are length restricted
>
> Eek! "Block.Name.1.1" and "Block.Name.1.b"'s?!

I think the key thing here is that wherever a dot hierarchy is allowable we
have not artificially restricted it in depth - as in the class.type or
bock.header areas - however from this indexing point of view (and given the
size constraint on udp packets) I think that we're unlikely to see a
greater
than 1 indexing depth employed. This indexing also leaves some flexibility
of allowing blocks to span messages as well but that is a whole other
discussion. There is no provision currently in xAP v1.2 for messages longer
than 1 packet length.


>
> I'll add some explicit helper code to automatically enable .1 and .2
> indexing to my framework as that'll help me deal with James' News
> messages and might make things a bit easier to use, but
".x.y"'s I'll
> leave to the user.

Seems the right approach

>
> I'll have to check that Block names can have multiple dotted
> components in my framework. Can't recall now if that is supported. It
> will be tonight though since it's already in the current spec.

Yep the spec does allow this

>
> >I don't like this and I wouldn't like Data.1 Data.2 either - plus
I do
> not
> >like the ability to include identical names twice within one body
- I
> think
> >everyone is now finding this problematic. At the very least later
> instances
> >should be deemed to supercede earlier ones.
>
> That's how I deal with such repeated cases of Data=This and Data=That
> in a single message block.

What sort of circumstance does this occur in ? I am trying to think of an
instance when it is necessary - I would have thought either different names
could have been used data1 data2(which is effectively what data.1 and
data.2
are) or where the info could be concatenated into one data name/value pair.
This indexing of the data name (to data.1 and data.2) implies that a schema
defines data as an expected name/value pair but can accept multiple
instances - as Mark said perhaps this is down to the particular schema
definition

>
> > > I think separating this into multiple blocks makes
processing
> easier,
> > > because the possible data in the block is much reduced, as
well
> as
> > > making the block schema much neater, but at the expense of a
very
> > > slight increase in data in a message body (ie the cost of
> repeating
> > > the block name plus a unique index value, and a little bit).
> >
> >In which case each of the above Lounge Hall Kitchen Outside would
be
> >separate bodies.
>
> I'd keep them all in the same block in this case.
>
> >It is a powerful feature but also quite complex in application -
for
> example
> >what happens when a header says Target=UKUSA.TempSensor.* and a
body
> has a
> >Target=*.*.Lounge - the actual body message should only really be
> acceptable
> >to a UKUSA.TempSensor.Lounge - a logical combination - this can
get
> quite
> >complex and several targets might appear in a body. At the moment
I
> think
> >this is feature of xAP that may not see much implementation. But
we
> tried to
> >leave it as flexible and powerful as possible - and of course it
is
> optional
>
> This is something I plan on leaving to the developer that uses my
> framework. Their app can pick up the Target line and then put the
> value into an instance of a xAPTargetAddress object. From there they
> get all the various benefits of that class.

If you supported targeting of message blocks within the framework
wouldn't it be easier to return to the user a calculated target address
that
makes use of the combinational function of the logic - perhaps as well as
the target info in the header and the target info from the block
separately?
I need to check if multiple targets are allowable within a body too ??
I do feel that this targeting of body parts complicates parsing a
xAP message quite significantly. It is no longer sufficient to just parse
the header to determine if the message applies to you. For example

xap-header
{.....
Target=UKUSA.Thermostat.Hall>
...}

body.part
{
Target=*.Thermostat.Lounge
SetPoint=23
}

Is actually a construct that causes the message body to be not
applicable to anyone. A simple xAP receiver UKUSA.Thermostat.Hall that
didn't implement body targeting resolution would accept this message and
change it's setpoint. I would be interested in Patricks comments here as it
appears that partial implementation of this 'optional' feature changes the
operation of a simple device.


>
> >- although I have asked elsewhere that exact targetting be a
MANDATORY
> >rather than optional requirement to facilitate polling.
> > >
> > > Anyway, was there any thinking on block name indexing in
previous
> > > discussions? I.e. Block.Name.1
> >
> >I think that is supported in the spec
>
> And thus it shall be supported in my xAP framework SDK ! Lots of
> little details in the spec I'm still picking up on, even several
> months down the line.

I think the natural progression after defining a spec is that when it is
applied in a real world people have different needs and applications - it
is
this real world experience that is now driving the xAP direction which is
good. The spec was deliberately created to be very flexible (no artificial
restrictions) to allow such changes to be introduced and still be
backwardly
compatible - the building blocks are all there and seem stable - what is
actually utilised in a real world may be only a partial featureset. Most of
the changes we need are policy rather than spec changes. We just need to
ensure that what is optional and what is mandatory doesn't change the
behaviour of a device - it might restrict it's operation but it shouldn't
behave differently.


Kevin
>
> S
> --
> Stuart Booth
> xAPFramework.net - a reusable xAP framework for .net
>
> <a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>
<a
href="/group/xAP_developer/post?postID=l7hRdfQ50FkW9ejMU2BsF_A_LxjaL8uSI65ZxotKdEjKPgWzIKWmtdLWglNO8OCSt7zvMHCKcAFdDPl7YSn1Gp4">stuart@x...</a>
>
> ------------------------ Yahoo! Groups Sponsor
---------------------~--
> >
> Get A Free Psychic Reading! Your Online Answer To Life's Important
> Questions.
> <a href="http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/dpFolB/TM";>http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/dpFolB/TM</a>
>
---------------------------------------------------------------------~-
> >
>
> To unsubscribe from this group, send an email to:
> <a
href="/group/xAP_developer/post?postID=BvkG7dUJyTIK6WR6xqIQzIb8kwrF4-VPVP9Jnxn_CKm9dVV3i8wt75vKNEnR6o1r1PAVa2xd22mBoqACtkU4bkrcCrZ85OJEOypvRM0wWe__qXSc">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>