> That's going to be problematic, because almost all of SQLite's usage > of underlying I/O is block-style, not stream-style, more akin to > accessing elements in a persistent byte array (with other practical > matters added on, of course) than to reading and writing streams. > You'd probably be better off just writing temporary files in both of > the cases you mention, unless (in the latter case) you actually have > per-block (or similar) crypto going on rather than purely streaming. > > (You do use seekp, but some underlying streams might not support it.)
I know this, in fact that's why I wrote that they are just ideas (reading from a socket was a bad idea) But a derivate of iostream could for example do lazy-decrypting by decrypting only blocks of data that are required, and would store all the writes in a buffer that is flushed (ie. re-encrypted) when the sync function is called For example a stream which handles a simple ROT-13 "encryption" can be written in ten minutes (if you know the internals of the iostream library) I really think there are a lot of things that you can do with streams _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
