01-05-2010, 07:07 PM
Hmmm. But how would a template designer get their sound files onto the iPhone? I don't think that's workable in the heavily regulated iPhone environment, where each application has its own sandbox file system. And I bet that many mobile and small-footprint devices will have a similar problem. Smartphone users aren't usually provided with a file explorer application. Maybe Android will be able to do this, but nobody else.
Further, any new client would need to be configured before use. If Rob's iPhone-loving friend comes over to his apartment, and Rob wants to show him his cool iPhone-controlled CQC system, he can't just give him the host, port, user name and password to put into the phone. He also has to load up the necessary sound files. No other aspect of RIVA currently requires this -- images, for instance, are pulled from the server as needed.
Perhaps I'm missing some clever approach; let me know if you have any suggestions. But it seems problematic. You note that the RIVA server may not be running on the same machine where the sound files are. But that is also the case with images, correct? Maybe you're imagining the WAV file being used to retrieve songs, large audio files, etc. that would reside on a separate A/V machine. I can see how that might be a problem. I was envisioning things more like system alert sounds, beeps and clicks, things to make the user interface nicer.
So I heavily favor the creation of a third cache of opaque data that the image server serves from in response to appropriate request paths. This would let me use sounds on the iPhone. And I may also be able to use the same mechanism for font downloads: when the client gets a request for a font it doesn't recognize, it asks the image server for Opaque::Fonts/TheFontName or some such, then installs the font locally. Just a thought.
Further, any new client would need to be configured before use. If Rob's iPhone-loving friend comes over to his apartment, and Rob wants to show him his cool iPhone-controlled CQC system, he can't just give him the host, port, user name and password to put into the phone. He also has to load up the necessary sound files. No other aspect of RIVA currently requires this -- images, for instance, are pulled from the server as needed.
Perhaps I'm missing some clever approach; let me know if you have any suggestions. But it seems problematic. You note that the RIVA server may not be running on the same machine where the sound files are. But that is also the case with images, correct? Maybe you're imagining the WAV file being used to retrieve songs, large audio files, etc. that would reside on a separate A/V machine. I can see how that might be a problem. I was envisioning things more like system alert sounds, beeps and clicks, things to make the user interface nicer.
So I heavily favor the creation of a third cache of opaque data that the image server serves from in response to appropriate request paths. This would let me use sounds on the iPhone. And I may also be able to use the same mechanism for font downloads: when the client gets a request for a font it doesn't recognize, it asks the image server for Opaque::Fonts/TheFontName or some such, then installs the font locally. Just a thought.