CompuServe Messages

I don't expect that some kind of encryption is difficult to add at the compression/decompression step, in fact, there are crunching utilities that do such things. However, I also figure we will not be doing our own trailblazing in the compression algorithm area, since there are multiple standards in this area now, and I expect that some of these existing standards would be difficult to beat as far as compression efficiency. Due to this, I expect that what we will do is to provide hooks to an external compression/decompression library (like squeezebox) and let other individuals have at the specialized cases like you describe. I encourage the utilization of libraries in this manner for a lot of features (or modules as well) because it allows for the plug-and play of alternative parts that might add features like you describe. For instance, a compression library like squeezebox could be utilized by a front-end "stub" library that calls squeezebox for the compression stages, but adds its own encryption stage. In this way, it would not be necessary to derive a specialized compression mechanism, and then be upstaged when a new standard comes out (and is perhaps implemented into a compatible library). If squeezebox (or similar) is improved, the stub library would presumably be compatible and therefore you'd get the features of the new squeezebox immediately, without waiting for someone to add them to the proprietary "encrypted" version. Keith