Slimp3 as a xAP display & controller

[max_adamiec]

I've spent the last couple of weeks thinking about the possible
functionality the slimp3 could provide in a xAP environment.

Currently Stuarts slimp3 conector only controls the slimp3, one way
communication from xAP to slimp3, there is no way for the slimp3 to
interact with the xAP network.

This is all well and good in a "push" situation. The slimp3 can
be
controlled as a specified event occurs eg. muting the sound when the
doorbell/phone rings.
It's no good for when the user wants to check if he has new mail, or
check the status from a weather station.
Basically the slimp3 can be controlled BY the xAP network but the
xAP network cannot be accessed/controlled/influenced at will by the
slimp3's user.

The slimp3 server software is open source, written in perl and open
to plugin modules:)
How about a slim plugin which can poll xAPp's, retrieve information
and display it?

You could expect the interface to go somthing like this

xAP information-->email-->inbox has x new messages-->message from.
-->message from.
-->weather station-->current temprature = 20'c
-->current humidity = damp
-->forecast = rain
-->comfort-->alarm state = away mode



I'm not a programmer (yet) but I suspect that the above is achievable
easily enough by making the final right push on the slim remote
activate a xAP message (with the relevant information) directed back
at the slims display (Stuarts connector comming into play here).

Pros-if you can launch a xAP message back to the slimp, you can send
one anywhere. The slim has just become an IR input device.
Cons- this sounds like an awful lot of programming for the plugin.
Each final right click/activation would need addressing to a
different xAPp. A lot of work for my first perl project.

Another way, this ones a bit of guesswork by the way, could we have
a xAPp database? POP3 pollers, weather station data, alarm states
could all be periodically sent and stored in the database. The
plugin would then be retrieving information from one xAPp instead of
several different ones. I'm guessing the coding for this would be
similar for each segment reducing the amount of debugging required
for individual components.

Personally, I like the idea of a database. Although this may change
as I learn about the plugin limitations.

I will have a go at a simple xAP message sending plugin as a
learning exercise. (Hopefully create a heirarchy, with the final
right step launching a xAP file. All .xap files are associated with
Stuart's Send App, so shouldn't have to include the body of the
message in the plugin, just refer to it location in a directory).

I'm not a programmer, don't know anything (yet) about perl. So,
please give me some pointers, wish lists, advice, heckle, anything
really:) Do you think I'm on the right track?

Max