RE: Schema Question

[Sullivan, Glenn]

That's kind of the way I saw it... send out all the messages that your
system can support, so that a limited-resource device can only filter on
the
messages that they NEED to interpret. ANd you are right, it is easy enough.
I just had the opposite assumption initially.

But now that I think about it some more, that might cause some problems.
For example:

*Let's assume your methodology

*Which means that there can be simple CID devices
**These only send a CID.Incoming class with a CID.Incoming block
*But there can also be Meteor devices, which will send two messages.
**One will be of class CID.Incoming with a CID.Incoming block
**The other will be of class CID.Meteor, with an Incoming.CallWithCID Block

*I want to create a CID-to-TTS app
*I want it to be able to intercept all Incoming CID messages
*Which means that, since I want to get all inbound calls, from a meteor or
not, I need to pick up messages with Class=CID.Incoming and grab data from
the CID.Incoming block

Sounds good so far...

*Now, I started making my xAPtts Application, using MS Agent
*I figure that I cant have a class=TTS.MSAgent without having a
Class=TTS.Basic in the schema
*And I can see needing the "Basic" class as a catch-all, to make
all TTS
devices speak, no matter what type.
*So my MSAgent app should listen for TTS.Basic messages and announce them.
*But MSAgent has many additional features, so I was going to make a Speak
block in the TTS.MSAgent Class, with additional items like Character and
Animation.
*Following the logic above, if I want my CID-to-TTS app to send a
TTS.MSAgent Speak message It should also send a TTS.Basic message, so that
non MSAgent TTS xAPplications will also speak the message.
*But now, my MSAgent TTS applications gets the TTS.Basic message, speaks
it,
and then gets the TTS.MSAgent message, and speaks that.

I guess I'm making a mountain out of a molehill, now that I type it all
out.
I can just set up a window during which the TTS app ignores tts.Basic
messages, to avoid duplications. Then I have to change the CID-to-TTS app
to send the "fancy" message first, then the basic message.

I guess it just seems silly to send out two messages. Can't I just create
optional parameters in the TTS.Speak block in TTS.Basic, and then the
"simpler" tts devices will ignore them? And then only have a
class called
TTS.MSAgent for blocks like DefaultCharacter.Change, or Status.Request?

But I've been xAP programming for all of two weeks, so I defer to you
guys...

Glenn

-----Original Message-----
From: Stuart Booth
To: <a
href="/group/xAP_developer/post?postID=5JztbA3pbDCtCxbdwUoD1JTc9KJeRTz4sqVXlE673K97iAH2rdjxWgoKUQy7TawlRB_QM3c9q8j5mG0TNjoeL2fS_hTNqq2d">xAP_developer@xxxxxxx</a>
Sent: 12/22/03 9:05 AM
Subject: Re: [xAP_developer] Schema Question

On Mon, 22 Dec 2003 09:00:07 -0500, "Sullivan, Glenn"
<<a
href="/group/xAP_developer/post?postID=HyRe0lxy3njgUgyhv9DS0TLqcvhzckQJBqC3pve_rtDAwxZY7CG6qGn3hc7DZ48GAiM96RikTJjHH06QZt9jT9M">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=_JLA7PGBjNh3P3uIATbGW0zkI3kqcX1c56s0YpmmB5IesiL-7lfD_OigfL4iVu1e8iaFkf5zfWhZwQ6GL_4">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>