Thanks for answering
> You claim that documentation is missing. Specifically what was not > documented? Well I was referring to the online documentation (sqlite.org/c3ref/vfs.html and sqlite.org/c3ref/io_methods.html) which don't explain the effects, possible return codes, etc. of some of the function. I recognize this was just an excuse for implementing them later (as your source code is impeccable) > The first major reason why there would be a problem is that you do not > support locking so if the stream ever referred to a file it would be > possible to corrupt it should another process access the file using the > SQLite library. I think that this is the stream creator's problem! Of course it would not be very efficient because the file would have to be locked for writing all the time, even if you just read it But the main reason why I would use streams is for other things like reading data from a socket or decrypting a file on-the-fly for example (these are just ideas) > Secondly you need to prevent exceptions from happening in any of your VFS > callbacks as they'll unwind the stack and not let SQLite's error recovery run. I don't think it's a problem either, a try-catch block around each function's body will do the trick Anyway I don't think about using this code in a real program for the moment, I just made it because of my love for modularity and because it looked like a nice idea _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
