RE: Multi-block message bodies

[Kevin Hawkins]

> -----Original Message-----
> From: Stuart Booth [mailto:<a
href="/group/xAP_developer/post?postID=CRS88Ub51JkzXFkN3F4gWJ8bm1-vizrcoAWZkS6j-BY0HK0Aw3_M5zlzrbU2PzguE6fcXuRvjmfvFFEIcXP0Cw">lists@x...</a>]
> Sent: 10 June 2003 20:26
> To: <a
href="/group/xAP_developer/post?postID=B2IAVW5WJ-E26193JKs-3n-kkXYgywXPTRZ5_RLTLf8-cV-rX2gkmlp9QTDvjunExJJjd4u7A8WLjyO5VJyIa2Haig">xAP_developer@xxxxxxx</a>
> Subject: [xAP_developer] Multi-block message bodies
>
> On Tue, 10 Jun 2003 17:47:26 +0100, "Kevin Hawkins"
> <<a
href="/group/xAP_developer/post?postID=7k50aGnCxLR203INzvL0gEBxUJVEj0lSUOCOUsSqYN0TGM6R5qQ_Uql0TaoL2jqFDPZhrxMjIzWMWJUaNww3GGmN">lists@u...</a>>
wrote:
>
> >And re Stuarts comment below - any feedback ? - I personally am
sort
> of
> >against having multiple bodies as the way to do this mainly
because I
> am
> >considering the size of the packets but maybe it's correct ??
>
> AIUI James wishes each block within a message body to be uniquelly
> named, hence Block.Name.1 and Block.Name.2
>
> As it happens I was reading the spec last night for something or other
> and I came across an example which references my.Block.1 etc in the
> "Wildcarding of address via Body (Multi-Block messages
only)" section.
>
> Seems like you guys have already been doing this type of thing
> already.

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
>
> My own thought was to keep data out of the block name, but I can see
> the usefulness of uniqueness in the names.
>
> For myself, I wasn't too wild on indexed data within each block:
>
> Block.Name
> {
> Data1=This }
> Line1=Wibble }
>
> Data2=That }
> Line2=Wobble }
> }

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.

However think on say a 4 channel dimmer status response

Status.response
{
Channel 1 =50%
Channel 2 =20%
Channel 3 =30%
Channel 4 =0%
)

or if channels were named

status.response
{
Lounge=50%
Hall=20%
Kitchen=30%
Outside=0%
)

>
> 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.

>
> Block.Name
> {
> Data=This
> Line=Wibble
> }
> Block.Name
> {
> Data=That
> Line=Wobble
> }
>
> I hadn't realised I could do block target addressing, but it's easy
> for a receiver app to add their own support for this using my
> xAPFramework classes, so I don't feel I need to add any explicit
> support for this in the SDK.

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
- 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
>
> It's only needed where multiple blocks of the same name exists. I'm
> wondering about adding some support for this in my framework and was
> curious to know if there was any specifics about this format e.g. such
> things as "must be sequential only within a single message
body".
>
> Block.Name.1
> { }
> Block.Name.2
> { }
>
> is okay, but
>
> Block.Name.3
> {
> }
>
> on its own wouldn't make sense.
>
> Or whether the data could be randomly indexed:
>
> Block.Name.1234
> { }
> Block.Name.2468
> { }

No opinion here - I think this is OK isn't it ??
>
> This seems to be getting towards including *data* with the block name,
> which strikes me as being wrong.

I agree but is it really data or a means of differentiating blocks - the
actual data should be included in a block too - as with the dimmer example

A sequential (although perhaps
> randomly ordered within a body, but preferably sequentially ordered)
> list seems useful and something I can add support for in my xAP
> framework code.
>
> Just curious.
>
I am conscious of complexity vs flexibility - when someone comes up with a
need for this sort of construct then they are likely to supply transmitter
and receiver xAp's to deal with the data - to them it is a godsend that the
spec is flexible but its there if needed. I suspect very few people will
use
this

K
>
> > > -----Original Message-----
> > > From: Stuart Booth [mailto:<a
href="/group/xAP_developer/post?postID=CRS88Ub51JkzXFkN3F4gWJ8bm1-vizrcoAWZkS6j-BY0HK0Aw3_M5zlzrbU2PzguE6fcXuRvjmfvFFEIcXP0Cw">lists@x...</a>]
> > > Sent: 01 June 2003 18:22
> > > To: <a
href="/group/xAP_developer/post?postID=B2IAVW5WJ-E26193JKs-3n-kkXYgywXPTRZ5_RLTLf8-cV-rX2gkmlp9QTDvjunExJJjd4u7A8WLjyO5VJyIa2Haig">xAP_developer@xxxxxxx</a>
> > > Subject: Re: [xAP_developer] Topic 1: Base Level Status
Schema
>
> [munch]
> > > This reminds me of what I've been wondering about James'
News
> feed. If
> > > you included data in the block name you can include the
status of
> each
> > > port in a separate message block in the message body, and
use the
> same
> > > format for each block.
> > >
> > > Is there any scope of including instance data in the block
name
> format
> > > e.g. Block.Name:Instance ?
> > >
> > > I've preferred to have data variables inside the blocks
though.
> It's
> > > data, not a type, after all.
>
> --
> 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=AYN3sZ-YpoppCfNGyrL44s70xdqcFmjt3mLoPzH6j3C946chc4M-vHWcy-py1mNejXwOmlM1ZNOeLMj7hWo">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=7s5PB2tZb_CF-WaGv8l_oKfLZ3_bUNwcZ8HhClGA1EWNKWVxxQ8o1ldx7ioaKOsVTNZT2uibQYpm8Z6FrCVXjc5iuJs0_luODb5BLOXdVnrv">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>