We would have several types of objects that we would support, and these would be extensible. I see for the initial server having "control" objects that would map to the Empeg's control set that we send over the serial port. Examples are VolUp and VolDown.

I noticed that the memo pad app on the Palm uses the first line of the memo as the file name. This is preserved on the recieving end and the obex_palm3 app uses that file name to save the memo to /tmp.

Presumably, you'd be able to write a Palm app that can specify the file name for each object it sent. Then Empire could use that file name to know which program to pass the data on to.

The simplest way I can think of to make it extensible is to just create a fifo for each app that wants to get data from Empire. For example, have a fifo called "command" and one called "playlist". From the Palm, you could have a page of buttons that send text to the "command" file and another daemon on the empeg reads from the command fifo that Empire writes to and passes those commands on to the player. The playlist fifo could pass the data on to a different daemon that would perhaps look at the first line and know whether you're asking to read the current list or if you're submitting a new one.

Yet another fifo could be the one that TTSd uses so you can beam a memo from your Palm titled "readme" (or "ttsd" or whatever) and Empire would pass that on to TTSd.

And maybe even have something so that memos titled "lyrics" get passed on to the upcoming lyric scroller. Not necessarilly intended as a useful way to display lyrics, but just as a way to view text files on the empeg.

If the incoming OBEX object's file name doesn't have a matching fifo, maybe Empire could play a short beep or something to let you know it doesn't know what to do with that data. All in all, it sounds like a very doable project! New plugins don't need to register with Empire and Empire doesn't even need to be restarted to detect them.