Except it's GPLed, so it can't be used in any closed-source apps, or any apps that you want to distribute on the App Store, without an explicit exception.
If you're not married to the license for philosophical reasons (which I would respect, it's your right), I'd suggest a change to something simple like BSD.
This would, of course, allow someone to take your code, change it, and not release their changes, but it would also make it usable to the majority of programmers.
>.."distribute on the App Store, without an explicit exception".
That is a good idea, thank you. I'll add such an exception so libzdb can be used by any iOS/OSX open source app on the app store. I'm a big fan of Open Source Projects and happy if they can find some alternative income such as from the app store. Growl for instance seems to do good there which I'm glad to see.
Otherwise, my goal with using GPL is to preserve the concept of copyleft with the library. The GPL only applies if you plan to distribute libzdb to third parties. In that case, my hope and the reason I use GPL is that any modification done to libzdb can be contributed back so others can benefit. Otherwise, you can do whatever you want with libzdb without any restrictions.
If you're really concerned about people not contributing back their changes, I'd first consider whether it'd be due to their unwillingness or maybe a cumbersome process of doing that.
For instance, I can't find anything on the website that would explain how to submit a patch. There's a mailing list and it'd be great by 2002 standards. Hosting this on GitHub (or any other site with a forking workflow that's just as smooth) would probably solve your problem without having to resort to imposing legal restrictions. There still would be a few companies/people unwilling to help but only a considerable minority.
If that is your intent, why not place it under LGPL. That way changes to the library must be published but the program that uses it can remain closed-source? As you have it now, the library is unusable for any commercial application. I thought it was a great match for a project of mine, but there simply is no way to actually use it with that license.
The LGPL requires that the end-user be able to replace the library with an API-compatible library and still run the program. That's arguably impossible with an iOS device, and certainly impossible if you don't provide at least object files that can be relinked. Even with object files (or source) they'd have to pay to register as an iOS developer.
I suspect the majority of developers using the LGPL don't realise, or perhaps even agree, with this intent, so you're probably unlikely to be sued, but it's what the license demands.
I didn't say that using the LGPL would give you the same possibilities as BSD. Sorry for the answer that only half fitted the question, in context of iOS and App Store, you are right.
If the author wants to use a GPL license, its his decision. But using a viral license in a support library is harmful in any case, as it destroys all ability to use it in a program that incorporates other pieces of code that might not be compatible with the GPL.
FWIW, I went to the website, clicked Documentation, and when nothing changed on the site except the button I started to wonder if the site was offline or my web browser had locked up. Then I clicked another link, noticed my scrollbar changed size, and realized you were updating content below the bottom of my screen due to the unusually enormous header.
Showing example code on the home page is a great idea, having the small thumbnail with the expand icon made it easy to jump in and see what their API looks like. Going to give this library a try soon :)
have you considered a varargs call for setting parameters with type codes? so something like
PreparedStatement_setArgs(p, 's', "a string", 'i', 42, 'f', 3.1415926);
would set arguments 1-3. i know it's not "OO", but i have done something similar in an internal lib for work and it's very useful and easy to use.
[edit] the number of parameters is assumed equal to the number of '?' in the query. i also have something similar for reading results from the ResultSet, but that required pointers and a count, and was much more likely to lead to errors.
> have you considered a varargs call for setting parameters with type codes?
Varargs are supported when building a prepared statement, but not for setting wildcards values. I see what you mean and how the client code can be made more compact. Still, I believe setting one by one value by explicit type may be better for readability, is less error prone and as you say, is more OO and orthogonal.
one more thing that i assume must work this way, but you don't seem to have documented, is how to test for exceptions. i guess SQL_Exception (a return value, right?) is false when there's no error?
related: do you have any examples that include all the error handling that would be necessary in a real app? how do you display the exception details (it seems to be an opaque type) to the user? perhaps i am missing something here (can't even find exception in the clickable API image)?
(wish i had known about this a few months ago as it would have saved me some work - thanks).
Thanks. The documentation for exceptions may be some clicks away, but it's there. Here's a direct link. http://www.tildeslash.com/libzdb/api-docs/Exception_8h.html Exceptions are a "true" exception implementation based on the Except code from David Hanson's excellent CII book. This makes it possible to write more compact code without peppering your C code with return code tests.
i have a fundamental question regarding this: instead of a pool of connections, is it possible to have an event-loop based aysnc-io in place ? this is with little experience with db's...
Yes[...]
Except it's GPLed, so it can't be used in any closed-source apps, or any apps that you want to distribute on the App Store, without an explicit exception.
If you're not married to the license for philosophical reasons (which I would respect, it's your right), I'd suggest a change to something simple like BSD.
This would, of course, allow someone to take your code, change it, and not release their changes, but it would also make it usable to the majority of programmers.