RE: Introduction

["Adam Stevens" <adam@xxxxxxx>]

> It is possible to add your own parameters into an existing
> schema in that they will then be ignored by other
> applications but you mustn't alter the usage of an existing
> parameter.

That's worth knowing.

> What we
> perhaps need is a broader CID schema not associated with say
> the Meteor.

Yup, I'd go with that.

> I
> also added 'Skype' for example as VoIP has several variant
> protocols.

Skype integration sounds interesting... I don't tend to use Skype myself
much now that I've gone down the hardware SIP route, but it's a nice
little system.

> One other concept worth using is that xAP addresses can optionally be
> broken into two components separated by a :

Sorry, I've snipped all that, but found it very interesting.  I think
I'm going to have to spend sometime playing with all this!

> Yes, it's a 3 step process but effectively still
> instantaneous on Ethernet.  The big gain is that everything
> becomes a network available information providor or device eg
> the CID lookup and you could drop in different applications
> that support the schema and it all still works,

Yes.  That, and redundant hardware certainly appear to be the biggies
with the whole xAP thing.  I really like the idea of a stack of device
types, each talking the same language.  It really does make the whole
integration thing so much easier.

> Originally I wrote an 'all in one' CID application.  Meteor
> input, STD database lookup, Caller name /call history DB, TTS
> and OSD messaging output, Slim server integration with on the
> fly dialled display, IR remote searchable callhistory  etc
> etc..  and of course it was never finished and never really
> suitable for other people who wanted a different OSD or CID
> device - or a US STD lookup or had an ABC modem

Been there, done that, got the T-shirt :-)

I've been giving all this a great deal of thought this evening.  I've
got some pretty positive feedback from some of the people who are
testing my Meteor/Sipura caller ID application at the moment, so I think
at this stage, it would almost be a shame to bin it just because xAP
modules already exist.  As I think you suggested earlier, I think I'll
probably leave it as it is for the moment, but see what I can do about
making the server talk xAP to the client - I haven't looked at it yet,
but I'm guessing that OSD schema is probably the way to go, as that way
the server (forgive me for using the term "server", I know the
idea of
xAP is to do away with such archaic expressions! :-) would be able to
talk to any xAP OSD, not just my "client" program (which,
effectively,
is just a OSD for PCs).

I'm aware that this *is* reinventing the wheel in some instances,
however I've already got the code base which I know to be pretty stable
as I've been running it for about 5 years!  There's also nothing
stopping me from separating the CID and the database levels out at a
later point, and hence broadcasting CID xAP as well.  At the end of the
day, it's an ideal way for me to get my head around the protocol, as
that would be all I'd have to worry about.  It also means that, once it
did xAP CID broadcasts, it could just as well be used in conjuction with
your xAPTel, and/or xAPLogger.

> Hubs are available as applications - your apps do need to be
> hub aware but it's a very easy thing to add and is
> transparent to the application once running.

Sounds to me like my first job is to write myself a Hub in Delphi... If
only to prove a concept to myself!

Thanks for all the info.

A.