RE: FW: xAP configuration protocol

[Kevin Hawkins]

Ahh - yes , good point - this is the same sort of thing as Stuarts 'non
persistant' application, - as such this xAP would again be a transmitter
only as it doesn't need to be hub aware.
We seem to be struggling with how to auto configure something that
is deaf - which if I think about it is a non starter.

So...

1) Do it manually
2) Have a shared temporary address for these sort of things and not
worry about conflicts on that address eg UID = FFFFFF00
3) Just log conflicts with the SNMP type idea to alert someone to
the need to manually reconfigure it
4) Move the device it clashes with to a new address (if that other
device can accommodate such a request)
5) Have something that generates heartbeats on behalf of such
devices (grimace)- really using this to reserve their UID - it has a side
effect that a service appears present when in fact it may not be.

K

> -----Original Message-----
> From: mark_harrison_uk2 [mailto:<a
href="/group/xAP_developer/post?postID=lDZ_RJgJU_qRzyq6M9s71c03CMbS2qVxwONzLT3ErqOQtWIoyr3Pi0-fzAEjvrKuBI0n-Ebb-nm1PKY">mph@a...</a>]


> There was another class of applications that couldn't send
> heartbeats. That was the application class that ran solely in event-
> triggered contexts.
>
> For example, a VBA application running in an Outlook context doesn't
> have an obvious mechanism to run timer events. However, it's trivial
> to write a VBA app that triggers on the receipt of a new email
> message... or a calendar event.
>
> You -could- write an app that integrated with Outlook and worked with
> heartbeats, but it would have to sit outside that context, and hook
> in in a more sophisticated way - perhaps a VBA application that sent
> some non-xAP form to IPC to a separate xAP-sender that listened for
> that IPC?
>
> Regards,
>
> Mark