From: stephan b. <st...@s1...> - 2004-12-18 00:02:05
|
Yo again! i've got a little lib, called zfstream, which adds client-transparent support for loading compressed files. For some months i've been thinking about making a more generic variant of it which can be extended by registering handlers. Looking at your I/O layer, believe that code would be a great basis for it. To give some background/context... consider this code: std::istream * is = zfstream::get_istream( "some_file" ); if( ! is ) { file not found or could not be opened } The input stream might actually be a compressed file, and the stream might be of type gzstream or bzstream (for gzip or bzip2, respectively). get_istream() examines the file to determine which type of decompressor to use, and passes back the appropriate stream type. The same goes for output files: Set the framework-wide policy: zfstream::compression_policy( zfstream::GZipCompression ) Now all calls like these use the requested compression: std::ostream * os = zfstream::get_ostream( "some_file" ); The ostream is compressed if the lib supports it (if configure script finds zlib) and if compression_policy() specifies it. If not, you get back an uncompressed stream. The point is, client code doesn't know if it's using compressed streams or not, and doesn't have to know. By making that more generic and adding handlers for your I/O classes, we could do: SomeIORequestBase * os = get_ostream( "http://s11n.net/s11n/sample.s11n.gz" ); and that might return a gzip-decompressing stream type. i've tried a couple times to implement custom std::streambuffer classes and i've failed miserably. Anyone out there who thinks that it isn't too much work to write std-stream wrappers for the P::IO layer? Take care, -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |