RE: Slim Conduit Feature request

[Kevin Hawkins]

> -----Original Message-----
> From: Stuart Booth [mailto:<a
href="/group/xap_automation/post?postID=t9PXWHRMNdJIuyOWxOczh9Jr3SMLS4GHDMXmFLfbk7bCEpb61AgmFKWqzXRZnyVuppL4pq7wceLVYLBh7pE_wHI">lists@x...</a>]
> Sent: 25 March 2004 13:36
> To: <a
href="/group/xap_automation/post?postID=AhTyijCHVSlX72u-_81RLmfahGKAJNYY8Z3Y25U4jHoyO-zHKxX5dQxNEqTpnVt58yQYF8_Xc1WGJAO8xdcjfrwrr2cDusDO">xap_automation@xxxxxxx</a>
> Subject: Re: [xap_automation] Slim Conduit Feature request

> Get the requests in whilst I'm in the area, just in case I
> don't come back to it for a while, as seems to be the way
> a lot of the time!

Well ... as you asked... none problematic more sort of 'on the list
somewhere' points

We talked about the possibility of a 'delay'/'queue' xAP application
debundled from the Slim connector - really meaning that you can throw
display messages at it and it then drives your Slim app as a realtime app.
This would then be very useful in other areas, particulary queuing display
messages for other output applications eg Tivo say . This I sort of see as
the abilty to send any xAP message to the app and ask it to send it onwards
to a destination sometime in the future - perhaps after a certain preset
delay or at a fixed time - a sort of scheduler even. It may have to 'spoof'
the original source to do this (??). Rolling this in with a queue manager
(and also a prority system) would be a very powerful helper application. I
know James was looking for such a feature for xAP Watcher etc.

Not a problem this bit I'll mention it in case it sparks some ideas... I
currently hit your connector quite hard to 'superimpose' text within an
existing SliMP3 displayed screen - requiring repeated reads to ascertain if
the underlying server displayed screens have changed at all, (even if you
write data via the CLI the underlying data returned via an enquiry is the
screen as the server intended it which is useful) . I can reduce this by
reasoning that screen text data only changes (from the servers perspective)
when the track changes or an IR key is pressed. So I watch for these events
and re-read the screen. I havent thought really whether this could be
accomplished more elegantly if it were embedded within the SliMP3 connector
itself by making use of its proximity to the CLI. The interface text does
change more quickly for example with the screensaver 'time' display or the
now playing elapsed/progress indicators

......Oh, although I briefly mentioned it above ... the 'priority queue'
...



K