V2

[ericsink]

I have started a branch for a version 2.0. This branch will cause some compatibility breaks. (Edit: To clarify, the only compatibility breaks I'm fairly certain about at this time are the deprecation of old platforms.)

The v2 branch:

• Uses SDK-style projects with multi-targeting
• Deprecates WP8, WP8.1, and pre-netstandard PCL profiles
• Uses Marshal.GetDelegateForFunctionPointer instead of DllImport

These are changes I've been wanting to make for a long time. Getting rid of the C++/CLI code simplifies things. Multi-targeting makes the build system easier.

And dynamic loading of the native code is SO much more flexible than DllImport. I should no longer have to build so many different copies of the pinvoke code, one for each possible name of the native library.

Unless I bump into an unexpected problem, I believe most of the complexity of the build system is going to go away.

I'm just getting started with this, but the new code already passes the xunit tests on Windows, so it looks promising.

Progress of this effort will be tracked here in this issue.

[ericsink]

Over in #253, @bricelam asked:

Are any other breaking changes planned for 2.0?

But I want to answer it here, so:

"planned"? No. Not yet anyway.

But I'm experimenting with some ideas that would be considered breaking changes. Well, they would be breaking changes at the SetProvider() layer anyway, even though I could probably hide them behind an unchanged Batteries.Init().

For example, currently, SetProvider takes an object that implements ISQLite3Provider, and here are quite a few different implementations, and somebody (usually the Batteres.Init() call) needs to:

SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_e_sqlite3())

In the current experimental v2 code, I (think I) only need one implementation of that class, and configuring which instance of the native code can be done lower. So the initialization could look something more like this:

SQLitePCL.Setup.Load("e_sqlite3.dll")

And SQLitePCL.Setup could potentially have a variety of methods to handle different use cases.

Another thing worth mentioning is that I believe all the nuget packages with names SQLitePCLRaw.provider.* would become unnecessary. Whether that is a breaking change depends on one's perspective I guess.

Anyway...

I won't actually finalize any decisions about breaking changes without seeking input from you and others. I will want to ask questions like, "Here is what I want to change, and why I think it's better, even though it will require a bit of work for others. Do you think this is worth the trouble?"

[ericsink]

Shorter and pithier:

I don't have a "plan" for version 2.0 yet. I just have some ideas and activity, and I want to make those things visible and open for discussion.

[ericsink]

And to be more consistent with the comment I just posted, I edited the top comment to add a clarifying remark.

Bottom line: Windows Phone 8.0 has gotta go, but I'm open-minded about everything else. :-)

[bricelam]

That all sounds good to me. If your 2.0 ships before our 3.0. These cleanup breaking changes are totally acceptable an in line with what we’re doing.

[AwsomeCode]

Plz include this as well #244

[ericsink]

@AwsomeCode Could you say more about how #244 is important to you?

Strictly speaking, I will probably not consider that item part of the v2 effort, because a change of the sqlcipher native code would be orthogonal to the other changes likely to appear in v2.

That said, I may get it done in the same time frame.

But it's problematic. The sqlcipher 4 code base is not, by default, compatible with files written by sqlcipher 3. That's gonna cause problems.

[AwsomeCode]

@ericsink Main reason is that iOS having issue with SQLCipher 3.
App is getting suspended/terminated whenever it's minimises, Switching Apps or Home button pressed.
For eg. Issue is if your filling form and if we switch app to check something on other app and switch back to main app and its get restarted. I think this is important for everyone.

#241
sqlcipher/sqlcipher#255

[ericsink]

@AwsomeCode Oh yeah, that issue. Thanks for reminding me.

[AwsomeCode]

@ericsink Thanks for your hard work 👍

[sjlombardo]

@AwsomeCode - I don't want this to sound like a plug, but SQLCipher 4 commercial edition for Xamarin.iOS would provide an immediately available fix for that issue. It is compatible with SQLitePCL.raw and (and dependent libraries) via bundle_zetetic, thanks to @ericsink.

[ericsink]

@sjlombardo I wish I had posted that reminder myself.

[ericsink]

Hey @bricelam -- shall I assume that support for winsqlite3.dll is still important for you folks?

The new approaches I am considering for v2 would allow me to remove a ton of complexity, which seems very cool. But keeping support for cdecl vs stdcall would force me to put some of that complexity back, and I'm feeling crabby about that.

More detail: AFAICT the only way to specify the calling convention for an unmanaged function pointer delegate is using an attribute, which, requires constant arguments, which means it is determined at compile time, which means supporting both calling conventions requires compiling two copies of the code.

Note also that AFAICT stdcall is only an x86 thing. It has no effect on x64 and ARM.

It is of course possible that dropping support for stdcall could affect other use cases as well, but winsqlite3 is the only one I know of.

And then there's my (not always popular) belief that, regardless of the platform, virtually all attempts to use a sqlite library provided by the system (instead of bundling one with the app) eventually result in sadness and regret.

Bottom line: keeping support for winsqlite3 seems to be extremely low bang-for-the-buck. So I would love to drop it if I can.

[bricelam]

Would there still be a hook (like ISQLite3Provider) for someone to implement it even if you didn’t enable it out of the box?

[ericsink]

(I'm interpreting your response as "Yes, we need this, but it's okay if people who use winsqlite3 have to do extra steps.")

Providing the ISQLite3Provider flexibility still involves more complexity than I wanted. But I also am not expecting to get everything I want. Even though I tossed you this question, I've been proceeding on the assumption that it wasn't actually likely that I could go forward with support for only one calling convention. :-)

Still, if you folks were to say, "Feel free to completely drop support for winsqlite3, and good riddance to it", then I would seriously consider Cdecl-only.

But like I said, my default path here is to find the least-ugly way to support both. And in the end, the result is still going to be far less ugly than the pre-v2 stuff.