Re: Multi-block message bodies

[Stuart Booth]

On Wed, 11 Jun 2003 01:09:20 +0100, "Kevin Hawkins"
<<a
href="/group/xAP_developer/post?postID=8DlaiCySvFdO3_BXGI8VC6yAg0FnE3AR8AC8jXio2CN2qLGRl0XSR4TZv1rE_jG_biW7XDJh2fZWeBlmCQ">lists@u...</a>>
wrote:

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

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.

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

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

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

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=9h1c-lf3jAAlILMCeJSzAbXIXE0i4n5_lkI8rmXfu_Zox4qdqeWBcow8mAoYIMgJT62YyBK9kZgwEKho6epw">stuart@x...</a>