Re: Schema Question

[Stuart Booth]

On Mon, 22 Dec 2003 09:00:07 -0500, "Sullivan, Glenn"
<<a
href="/group/xAP_developer/post?postID=Q8yZV7I68Eu-NcvPvT0KE3_x1pDzgXRNPBLOatVF4HzG3TEWipcYZFAn-d548IPsr4CnHaQgym5scuJ8eHI">gsullivan@d...</a>>
wrote:

>In the CID schema, there is a class CID.Incoming, with a block names
>CID.Incoming. But there is also a class CID.Meteor that has a very
similar
>(Identical really) block named Incoming.CallWithCID.

As you've spotted CID.Incoming is meant to be a pure CID info block,
generalised across absolutely all CID devices.

The CID.Meteor schema contains messages that cover all the information
specific to that device. My thinking was that since it's both
implicitly a generic CID device and a Meteor device I'd send out both
CID.Incoming (from class CID.Incoming) and Incoming.CallerWithCID
(from class CID.Meteor).

There's a possibility of receiving a call with no CID information so
class CID.Meteor supports this separately. In this case there's no
class CID.Incoming message I can reasonably send.

Block naming. I've got better at that more recently than when some of
us cooked up that CID schema. Mostly I've just reused the same name as
the schema in early efforts, but lately I've made them more compact. I
used to always force a Block.Name format name out of it, but often
just use Block { } nowadays if it feels right.

>If I were writing an App to interface with the Meteor, is it my
responsibity
>to send a message in both formats? Or is it the responsibility of the
>"receiving" application to be able to hear both types of
messages?

That's an interesting one. I'd say that since it's hopefully easy
enough for you to do so, why not send both the general CID and Meteor
CID messages? That way you don't push the responsibility onto every
other client application to deal with a maybe 'missing' message it
might expect.

BTW, xFx wraps those CID message classes into some objects it can use,
but it has a dependency on another type from another DLL. I've never
really got back to it to tidy it all up. Huge todo lists and a
distinct lack of time I'm afraid. Saves you having to add in all the
message content all the time manually though.

HTH?

S
--
Stuart Booth <<a
href="/group/xAP_developer/post?postID=yEObkoYJxtODkl0V_YL_w_rj6-vzxDtgHsRv3enH2Zg9UUhftCf9KT5Hvh4PqK5BLx-4sq1YCZNdBQvilg">stuart@x...</a>>
xAPFramework.net - a xAP software development framework for .net

<a href="http://www.xapautomation.org/";>http://www.xapautomation.org/</a>
<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>