On Fri, 3 May 2002, Reza Naima wrote:
Yeah, that sounds fairly high level. I've implemented most everything but the decoding already. So, how do you plan on doing backward seeking with your implementation?
I don't. I've scrapped the original Receiver model of retrieving a song and playing it. I've turned the Receiver into a dumb decoder of RTP streams and displayer of screen blit updates and a collecter and dispenser of IR / keypad inputs (though the display server and input dispatcher are as-yet unimplemented).
Basically, in my world, the server is responsible for dumping out an RTP stream, to which the Receiver(s) tune in. I'm planning on updating the server (Obsequieum, currently) to support "locked" and "unlocked" streams, then giving the Receiver's inputs to the server to control the "unlocked" streams.
A "locked" stream is one that several receivers (and other RTP listeners) might be listening to, therefore it wouldn't do to have them competing for "control" of the stream. An "unlocked" stream is one that one Receiver is listening to (presumably, although you could opt for anarchy). All of that receiver's inputs would be able to modify the unlocked stream's contents.
Right now, I just use the web interface to Obsequeium, and don't even bother with any controls on the receiver.