Feedback requested on proposed UWP-specific change in v2

[ericsink]

Short summary: In v2 (the upcoming release, see #255), SQLitePCLRaw would no longer call sqlite3_win32_set_directory(). The app would have to do this itself.

Details:

Using SQLite with UWP requires telling SQLite where the sandbox directories are. In the 1.x releases, this has been done inside SQLitePCLRaw with the following two calls, which (for this proposal) would need to be done by the enclosing app or framework:

    sqlite3_win32_set_directory(/*data directory type*/1, Windows.Storage.ApplicationData.Current.LocalFolder.Path);
    sqlite3_win32_set_directory(/*temp directory type*/2, Windows.Storage.ApplicationData.Current.TemporaryFolder.Path);

There are 3 things I dislike about doing these calls inside SQLitePCLRaw:

1. These calls initialize the SQLite library, which means things like sqlite3_config() can no longer be called.
2. The directories chosen might not be the ones the app wants to use.
3. These calls add significant complexity to my build system, which I have been desperately trying to make simpler.

Okay, so probably the most credible gripe here is (1). I consider it important that SQLitePCLRaw begin with the SQLite library in an uninitialized state so the enclosing app/framework has full flexibility. Right now, UWP is an exception to that rule.

If you want to label (3) as laziness on my part, I'm okay with that, but at least its honorable laziness. Simpler is better. And the additional build system complexity is hard to swallow just to get a feature that (a) causes problems, and (b) may not be what all users want, and (c) only affects UWP.

When v2 is released, I will publish a list of breaking changes, tentatively including this one.

Anyway, I'm asking for feedback on this. I might hear something to change my mind. :-)

[ericsink]

The proposed change did happen in v2.