[SQL-Connectivity] Is Boost interested in CppDB?
Hello, I have recently released a new SQL Connectivity library: General ------- Documentation : http://art-blog.no-ip.info/sql/cppdb/ Mirror Docs. : http://cppcms.sourceforge.net/sql/cppdb/ Download : https://sourceforge.net/projects/cppcms/files/cppdb/ Features -------- - Performance is the primary goal - make fastest possible SQL connectivity as possible - Transparent connection pooling support - Transparent prepared statements caching - Dynamic DB modules loading and optional static linking - Full and high priority support of FOSS RDBMS: MySQL, PostgreSQL, Sqlite3 - Support as many RDBMSs as possible via cppdb-odbc bridge - Simplicity in use - Locale safety - Support of both explicit verbose API and brief and nice syntactic sugar What it is not: --------------- This is not ORM library and not supposed to be so. This is something similar to what JDBC gives to JDK and QtSql gives to Qt and more. Boost Interest -------------- Currently I'm think whether should I boostify it, release it under BSL (currently it is LGPLv3) and submit it for formal review in boost or shouldn't I? Why do I ask, not because I'm thinking it is not good enough but rather because I feel that the "boostification" effort would be wasted at this point. For about half a year ago I had submitted a Boost.Locale for formal review, I use it under other namespace as part of CppCMS project all the time and in fact I receive most request and bug reports for Boost.Locale via CppCMS project and not via CppCMS.Locale so basically I have to handle two projects and synchronize between them all the time, and Boost.Locale is still stuck in review queue. So does it worth the effort? So before I do any steps forward may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily). Regards, Artyom
On Tue, Dec 14, 2010 at 3:18 PM, Artyom <artyomtnk@yahoo.com> wrote:
- Performance is the primary goal - make fastest possible SQL connectivity as possible - Transparent connection pooling support - Transparent prepared statements caching - Dynamic DB modules loading and optional static linking - Full and high priority support of FOSS RDBMS: MySQL, PostgreSQL, Sqlite3 - Support as many RDBMSs as possible via cppdb-odbc bridge - Simplicity in use - Locale safety - Support of both explicit verbose API and brief and nice syntactic sugar
How is this different from SOCI and why should I use CppDB over SOCI?
Boost Interest --------------
Currently I'm think whether should I boostify it, release it under BSL (currently it is LGPLv3) and submit it for formal review in boost or shouldn't I?
Why do I ask, not because I'm thinking it is not good enough but rather because I feel that the "boostification" effort would be wasted at this point.
For about half a year ago I had submitted a Boost.Locale for formal review, I use it under other namespace as part of CppCMS project all the time and in fact I receive most request and bug reports for Boost.Locale via CppCMS project and not via CppCMS.Locale so basically I have to handle two projects and synchronize between them all the time, and Boost.Locale is still stuck in review queue.
So does it worth the effort?
So before I do any steps forward may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily).
I'd say, it would be good to have a Generic Storage library that abstracts the details of whether it's being saved to a file, to a database, or to some other service in Boost. This way generic algorithms that deal with stored objects/data can be implemented and have "containers" or "silo's". Also, this way, anybody can adapt their storage client libraries to this Generic Storage API (if it's ever invented or agreed upon). That said, I'd really not like to use code that is anywhere near the GPL in all my projects. If releasing under the Boost license is an option for you, I think that would be the single thing that I would expect for anything being submitted for review to Boost. As for me, I'm not really satisfied with having to deal with niche libraries being made part of Boost (i.e. in this case the niche is database access) when there's a much more generic problem that needs solving (specifically, the abstraction of storage). If I'm interested is another question, and the answer to that would be: if you can show that your library is better than SOCI, then I might be interested in using it -- but I'm not touching code that is anywhere near the LGPL or the GPL for that matter if I can help it. Thanks and I hope this helps. -- Dean Michael Berris deanberris.com
- Performance is the primary goal - make fastest possible SQL connectivity as possible - Transparent connection pooling support - Transparent prepared statements caching - Dynamic DB modules loading and optional static linking - Full and high priority support of FOSS RDBMS: MySQL, PostgreSQL, Sqlite3 - Support as many RDBMSs as possible via cppdb-odbc bridge - Simplicity in use - Locale safety - Support of both explicit verbose API and brief and nice syntactic sugar
How is this different from SOCI and why should I use CppDB over SOCI?
Before I answer this question I'll tell that I'm familiar with SOCI, I used it for a while and I even had submitted several patches (for example dynamic backend loading implementation) to SOCI so I had reasons to implement something different then SOCI. Lets start from clear advantages: 1. Transparent prepared statements caching - it gives with 0 effort significant performance boost. 2. Transparent use of connection pooling (only you need to add an option in connection string). 3. Full support of Sqlite3 and MySQL (SOCI's implementation of them is very poor) 4. Unicode Support in ODBC, i.e. you can use Unicode with MS SQL Server that does know speaks in UTF-8, SOCI does not support this. 5. Support of both prepared and unprepared statements. Few additional and less obvious points : 1. When last SOCI version was released? 2 Years ago, non-GIT soci version has lots of bugs and issues. So basically you need to use git version to use up-to-date SOCI. 2. SOCI was originally created as OCI wrapper and has some "Oracle quircks" - but this is a metter of tase. Don't get me wrong, I like SOCI but I still think that my library provides some important added values that SOCI does not.
That said, I'd really not like to use code that is anywhere near the GPL in all my projects. If releasing under the Boost license is an option for you, I think that would be the single thing that I would expect for anything being submitted for review to Boost.
[...]
If I'm interested is another question, and the answer to that would be: if you can show that your library is better than SOCI, then I might be interested in using it -- but I'm not touching code that is anywhere near the LGPL or the GPL for that matter if I can help it.
First of all it is not GPL it is LGPL that is absolutly useable in any propriatary closed source project. It just keeps incurages users to release fixes they do. IMHO LGPL is much closer to BSL then GPL and this is probably what many developers should understand, and basically if you use SOCI for example with MySQL then you should know that you use GPL code, and when you develop almost any application under Linux you do use LGPL/GPL code. So ingoring this fact is just ignoring real world situation. I would say that I'm going to release it under BSL for being it part of Boost as it has significant advantage to have library in Boost. But other then that I'd prefer to keep it LGPL meanwhile. Best Artyom
On Tue, Dec 14, 2010 at 4:28 PM, Artyom <artyomtnk@yahoo.com> wrote:
How is this different from SOCI and why should I use CppDB over SOCI?
[snip]
Lets start from clear advantages:
1. Transparent prepared statements caching - it gives with 0 effort significant performance boost.
Okay.
2. Transparent use of connection pooling (only you need to add an option in connection string).
Cool.
3. Full support of Sqlite3 and MySQL (SOCI's implementation of them is very poor)
Alright, that's good.
4. Unicode Support in ODBC, i.e. you can use Unicode with MS SQL Server that does know speaks in UTF-8, SOCI does not support this.
Right. So how do you support Unicode that's not going through ODBC?
5. Support of both prepared and unprepared statements.
That sounds good.
Few additional and less obvious points :
1. When last SOCI version was released? 2 Years ago, non-GIT soci version has lots of bugs and issues. So basically you need to use git version to use up-to-date SOCI.
You're talking about SOCI 3 right? I don't see how using the git version would be a problem though.
2. SOCI was originally created as OCI wrapper and has some "Oracle quircks" - but this is a metter of tase.
Yeah, but... the quirks aren't really that bad.
Don't get me wrong, I like SOCI but I still think that my library provides some important added values that SOCI does not.
Sure, but how does your interface look like? The good thing with SOCI is that the interface is nice and easy to deal with. Sure it has some issues with some underlying details, but largely since you're dealing with database access, it's easy to see that the bottleneck is typically not the library accessing the DB. That said though, if your implementation is really much faster than implementations that use SOCI, then that would be a compelling difference. Have you measured the effect of CppDB over SOCI -- for example, did you try retrieving a record of 1000 rows and measured the positive effect that CppDB brings over SOCI?
That said, I'd really not like to use code that is anywhere near the GPL in all my projects. If releasing under the Boost license is an option for you, I think that would be the single thing that I would expect for anything being submitted for review to Boost.
[...]
If I'm interested is another question, and the answer to that would be: if you can show that your library is better than SOCI, then I might be interested in using it -- but I'm not touching code that is anywhere near the LGPL or the GPL for that matter if I can help it.
First of all it is not GPL it is LGPL that is absolutly useable in any propriatary closed source project. It just keeps incurages users to release fixes they do.
LGPL means I cannot do a private fork if I'm offering a service to clients and/or enhancing it in case I bundle it with my product. The reason people still stay away from LGPL is precisely because of these two issues I bring up. This is also the reason why permissive licenses like MIT, BSD, and similar licenses are more "commercial friendly".
IMHO LGPL is much closer to BSL then GPL and this is probably what many developers should understand, and basically if you use SOCI for example with MySQL then you should know that you use GPL code, and when you develop almost any application under Linux you do use LGPL/GPL code. So ingoring this fact is just ignoring real world situation.
Yes, which is why commercial products either have to pay MySQL AB (now Oracle) for a license to use MySQL that's released under a non-GPL license. At least people have that option. In case you're working on FOSS -- which SOCI is -- you're exempt from the GPLv2 virus. [0] Also, Linux has a binary linkage exception on the system calls, and so does libstdc++, glibc, and all the base libraries that come with Linux. That's different from developing a library that's meant to be open source. Of course it is your library, and if you don't want to release it under the BSL at this time, then I don't see why you should. [0] http://www.mysql.com/about/legal/licensing/foss-exception/
I would say that I'm going to release it under BSL for being it part of Boost as it has significant advantage to have library in Boost. But other then that I'd prefer to keep it LGPL meanwhile.
Sure, but I think one of the requirements for review would be that the code is under the BSL. So the real reason is, do you want to submit it to Boost in case others (like me) want to see your library in Boost. That said, others might (like me) not touch your code or even look at it because it's under the LGPL, so it's really going to be up to you. ;) -- Dean Michael Berris deanberris.com
4. Unicode Support in ODBC, i.e. you can use Unicode with MS SQL Server that does know speaks in UTF-8, SOCI does not support this.
Right. So how do you support Unicode that's not going through ODBC?
Almost every database around fully supports Unicode - sqlite3, postgresql, mysql and many others - they use UTF-8 as the text encoding without any problems. So as long as you keep working with UTF-8 you are on the right way, ODBC backend knows to convert UTF-8 to UTF-16 and backward for thous databases that do not support UTF-8 naively (i.e. MS SQL Server).
You're talking about SOCI 3 right?
I don't see how using the git version would be a problem though.
As long as you use it on your own and not have to recommend SQL library for customers. Also git-version tends to break once in a while.
Don't get me wrong, I like SOCI but I still think that my library provides some important added values that SOCI does not.
Sure, but how does your interface look like? The good thing with SOCI is that the interface is nice and easy to deal with.
I didn't post the link to the tutorial for nothing :-) See: http://art-blog.no-ip.info/sql/cppdb/ http://art-blog.no-ip.info/sql/cppdb/intro.html http://art-blog.no-ip.info/sql/cppdb/stat.html http://art-blog.no-ip.info/sql/cppdb/query.html Also unlike SOCI it allows both verbose API and syntactic sugar: sql << "INSERT INTO foo values(?,?)" << x << y << exec; or statement st = sql.prepare("INSERT INTO foo values(?,?)"); st.bind(1,x); st.bind(2,y); st.exec(); Depending on what do you prefer.
That said though, if your implementation is really much faster than implementations that use SOCI, then that would be a compelling difference. Have you measured the effect of CppDB over SOCI -- for example, did you try retrieving a record of 1000 rows and measured the positive effect that CppDB brings over SOCI?
The primary advantage is using prepared statements caching that gives boost (depending on engine) of about 20% to 150% percents. But executing same queries in same way would give close performance to native client.
That said, I'd really not like to use code that is anywhere near the GPL in all my projects.
First of all it is not GPL it is LGPL that is absolutly useable in any propriatary closed source project. It just keeps incurages users to release fixes they do.
LGPL means I cannot do a private fork if I'm offering a service to clients and/or enhancing it in case I bundle it with my product.
LGPL does not prevent forking. It just requires provide your client on request the changes you did in your private fork. It is fine to bundle the DLL of your private fork in proprietary project as long as you can provide sources for this DLL you had changed and I think this is quite fair requirement. Many... Many proprietary projects do this.
The reason people still stay away from LGPL is precisely because of these two issues I bring up. This is also the reason why permissive licenses like MIT, BSD, and similar licenses are more "commercial friendly".
I agree this is simpler to deal with MIT, BSD (3 cluse), BSL code then with LGPL... but it is not as hard as many see this. There is just a big fobia of everithing connected to a stuff that includes 3 letters "GPL"
Of course it is your library, and if you don't want to release it under the BSL at this time, then I don't see why you should.
[0] http://www.mysql.com/about/legal/licensing/foss-exception/
Speaking of exceptions, BSL is not one of the licenses under MySQL foss-exeptions.
That said, others might (like me) not touch your code or even look at it because it's under the LGPL,
I would say - their loss. In any case, if it comes to Boost it would be BSL licensed. Regards, Artyom
Hi, I was starting a similar project, but focused only on sqlite3. I was really missing that support in SOCI, that I would have loved to use. I saw your APIs and it seems cleaner than SOCI and it is actually the way I wanted to do my own lib, having a separated statement and results seems cleaner in a long term. However I think you are missing the boost integration (tuple, optional...) that SOCI has. Furthermore, I would recommend to use a already existing atomic int or ref counted implementation in boost. I also would like such a lib under the Boost license, because I want it to be statically linked to my project and the LGPL is preventing it. Best regards, Sylvain
Hi, On 14/12/2010 10:45, Artyom wrote:
You're talking about SOCI 3 right?
I don't see how using the git version would be a problem though.
As long as you use it on your own and not have to recommend SQL library for customers. Also git-version tends to break once in a while.
Please note that your argument about release schedule of the SOCI library is very transient by nature. It will become out of date with the next release of SOCI (whenever it happens).
Sure, but how does your interface look like? The good thing with SOCI is that the interface is nice and easy to deal with.
Also unlike SOCI it allows both verbose API and syntactic sugar:
SOCI does support several interfacing styles: http://soci.sourceforge.net/doc/interfaces.html
Depending on what do you prefer.
There is just a big fobia of everithing connected to a stuff that includes 3 letters "GPL"
Yes. But you have to address it and if you try to do it by "educating" everybody on this matter, then you will only alienate yourself. You have to bend to user expectations. Bending user expectations to fit your product is possible only if the product has no competition in its niche, which is not the case here.
That said, others might (like me) not touch your code or even look at it because it's under the LGPL,
I would say - their loss.
You still have to prove it. :-)
In any case, if it comes to Boost it would be BSL licensed.
You got it backwards. It must be BSL to attract attention on this list, not the other way round. Cheers, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Also unlike SOCI it allows both verbose API and syntactic sugar:
SOCI does support several interfacing styles:
Sorry, you are right, missed this somehow. Thanks for correction, Artyom
On Tue, Dec 14, 2010 at 5:45 PM, Artyom <artyomtnk@yahoo.com> wrote:
4. Unicode Support in ODBC, i.e. you can use Unicode with MS SQL Server that does know speaks in UTF-8, SOCI does not support this.
Right. So how do you support Unicode that's not going through ODBC?
Almost every database around fully supports Unicode - sqlite3, postgresql, mysql and many others - they use UTF-8 as the text encoding without any problems.
So as long as you keep working with UTF-8 you are on the right way, ODBC backend knows to convert UTF-8 to UTF-16 and backward for thous databases that do not support UTF-8 naively (i.e. MS SQL Server).
Yes, but more specifically I should have asked, does your library natively support wide strings (std::wstring) and handle the conversion from std::wstring to the appropriate UTF-8 encoding in narrow strings API's or the native multi-byte string APIs of the libraries?
You're talking about SOCI 3 right?
I don't see how using the git version would be a problem though.
As long as you use it on your own and not have to recommend SQL library for customers. Also git-version tends to break once in a while.
Sure, much like how Boost breaks even in regular releases. ;)
Don't get me wrong, I like SOCI but I still think that my library provides some important added values that SOCI does not.
Sure, but how does your interface look like? The good thing with SOCI is that the interface is nice and easy to deal with.
I didn't post the link to the tutorial for nothing :-)
Ha! I missed that part, thought the links were just for reference documentation, was too lazy to look at the information there. ;)
Also unlike SOCI it allows both verbose API and syntactic sugar:
sql << "INSERT INTO foo values(?,?)" << x << y << exec;
or
statement st = sql.prepare("INSERT INTO foo values(?,?)"); st.bind(1,x); st.bind(2,y); st.exec();
Depending on what do you prefer.
Cool. :)
That said though, if your implementation is really much faster than implementations that use SOCI, then that would be a compelling difference. Have you measured the effect of CppDB over SOCI -- for example, did you try retrieving a record of 1000 rows and measured the positive effect that CppDB brings over SOCI?
The primary advantage is using prepared statements caching that gives boost (depending on engine) of about 20% to 150% percents.
But that's dependent on the type of the query and the backend. Have you measured just the overhead/difference of just CppDB?
But executing same queries in same way would give close performance to native client.
Okay, I can believe that.
LGPL means I cannot do a private fork if I'm offering a service to clients and/or enhancing it in case I bundle it with my product.
LGPL does not prevent forking. It just requires provide your client on request the changes you did in your private fork.
It is fine to bundle the DLL of your private fork in proprietary project as long as you can provide sources for this DLL you had changed and I think this is quite fair requirement.
Many... Many proprietary projects do this.
Yes, but not all my clients want to have to release changes they make to the libraries they use. This is where more permissive licenses make sense -- and this is the same reason why the BSL is actually better in most respects for libraries than the LGPL.
The reason people still stay away from LGPL is precisely because of these two issues I bring up. This is also the reason why permissive licenses like MIT, BSD, and similar licenses are more "commercial friendly".
I agree this is simpler to deal with MIT, BSD (3 cluse), BSL code then with LGPL... but it is not as hard as many see this.
It actually is as hard as it sounds. <rant> First, I cannot make changes to the library that I don't want to share. There may be a lot of reasons for this for example, if I've developed my proprietary system and proprietary protocol for DB access. In this case I cannot write a backend that talks with my proprietary system because the LGPL requires me to release these changes when I distribute them in my software. That's a non-starter for proprietary software developers. Second, the politics of LGPL are just incompatible with proprietary extensions. Imagine if someone was developing a device and wanted to create proprietary extensions to that underlying system and not have to release the source to these proprietary extensions -- and a C++ runtime on top of it. Because libstdc++ is under the GPL, this means the changes to the sources would have to be made public. Even if you had an LGPL-licensed standard library you're *forced* to release changes when you distribute the binaries. This kind of politics is what is deterring proprietary software developers and consultants from recommending and supporting the GPL and the LGPL. This is also why people are working on other (better?) implementations of the standard library and compilers that don't have this viral license. </rant> There are a ton more reasons why the dogmatic view that all software should be Free as in Speech doesn't work well in business -- and in the business of software, there's usually more than one way to do things. I don't see a compelling reason then to have to sacrifice the principle of tolerance and neutrality if I have other choices for database client libraries than one that is under the GPL/LGPL. :)
There is just a big fobia of everithing connected to a stuff that includes 3 letters "GPL"
For good reason. For a case study on why, read up on the case that LinkSys ran into when they embedded Linux in their WRT routers. Also, there's the issue with why MySQL's development model was a bad idea; that having all copyright assigned to just one person/entity lends itself to abuse.
Of course it is your library, and if you don't want to release it under the BSL at this time, then I don't see why you should.
[0] http://www.mysql.com/about/legal/licensing/foss-exception/
Speaking of exceptions, BSL is not one of the licenses under MySQL foss-exeptions.
Okay, so that means the Open Source MySQL client libraries is a non-starter for non-GPL code. That sucks.
That said, others might (like me) not touch your code or even look at it because it's under the LGPL,
I would say - their loss.
In any case, if it comes to Boost it would be BSL licensed.
It's the other way around -- the less users who'll use your library, it's your loss. Also, if you want it in Boost, it would have to be released under the BSL. :) -- Dean Michael Berris deanberris.com
4. Unicode Support in ODBC, i.e. you can use Unicode with MS SQL Server that does know speaks in UTF-8, SOCI does not support this.
Right. So how do you support Unicode that's not going through ODBC?
Almost every database around fully supports Unicode - sqlite3, postgresql, mysql and many others - they use UTF-8 as the text encoding without any problems.
So as long as you keep working with UTF-8 you are on the right way, ODBC backend knows to convert UTF-8 to UTF-16 and backward for thous databases that do not support UTF-8 naively (i.e. MS SQL Server).
Yes, but more specifically I should have asked, does your library natively support wide strings (std::wstring) and handle the conversion from std::wstring to the appropriate UTF-8 encoding in narrow strings API's or the native multi-byte string APIs of the libraries?
No, as you don't need "wide" strings to use Unicode and actually wide strings are not native ones for almost every database. So for working with Unicode in CppDB you should use UTF-8. Artyom
On Tue, Dec 14, 2010 at 7:58 PM, Artyom <artyomtnk@yahoo.com> wrote:
Yes, but more specifically I should have asked, does your library natively support wide strings (std::wstring) and handle the conversion from std::wstring to the appropriate UTF-8 encoding in narrow strings API's or the native multi-byte string APIs of the libraries?
No, as you don't need "wide" strings to use Unicode and actually wide strings are not native ones for almost every database.
Okay. So that means people using std::wstring have to deal with converting to UTF-8 encoded std::string on their own. Sounds like a pain in Windows defaulted to use std::wstring in applications. :/
So for working with Unicode in CppDB you should use UTF-8.
OK -- Dean Michael Berris deanberris.com
On 12/14/2010 7:07 AM, Dean Michael Berris wrote:
On Tue, Dec 14, 2010 at 7:58 PM, Artyom<artyomtnk@yahoo.com> wrote:
Yes, but more specifically I should have asked, does your library natively support wide strings (std::wstring) and handle the conversion from std::wstring to the appropriate UTF-8 encoding in narrow strings API's or the native multi-byte string APIs of the libraries?
No, as you don't need "wide" strings to use Unicode and actually wide strings are not native ones for almost every database.
Okay. So that means people using std::wstring have to deal with converting to UTF-8 encoded std::string on their own. Sounds like a pain in Windows defaulted to use std::wstring in applications. :/
Converting between Unicode encodings should be a separate library anyway. Was there not someone working on such a cross-platform library for Boost ? What happened to it ? Was it scrapped because of possible Unicode support in C++0x ? I apologize for taking this thread off-topic but I think that any library using a particular Unicode encoding for its strings should be exempt from the criticism that it does not have functionality dealing with converting between Unicode encodings.
Artyom, that posted the CppDB library is also the author of boost::locale that is one of the libraries targeted to be proposed to boost to manage Unicode and relaetd subjects. UTFCPP was also proposed to boost some time ago. boost::locale is more about locale and localization system while UTFCPP is only about convertions between different UTF versions,using std::base_string strings. On Tue, Dec 14, 2010 at 14:45, Edward Diener <eldiener@tropicsoft.com>wrote:
On 12/14/2010 7:07 AM, Dean Michael Berris wrote:
On Tue, Dec 14, 2010 at 7:58 PM, Artyom<artyomtnk@yahoo.com> wrote:
Yes, but more specifically I should have asked, does your library natively support wide strings (std::wstring) and handle the conversion from std::wstring to the appropriate UTF-8 encoding in narrow strings API's or the native multi-byte string APIs of the libraries?
No, as you don't need "wide" strings to use Unicode and actually wide strings are not native ones for almost every database.
Okay. So that means people using std::wstring have to deal with converting to UTF-8 encoded std::string on their own. Sounds like a pain in Windows defaulted to use std::wstring in applications. :/
Converting between Unicode encodings should be a separate library anyway. Was there not someone working on such a cross-platform library for Boost ? What happened to it ? Was it scrapped because of possible Unicode support in C++0x ?
I apologize for taking this thread off-topic but I think that any library using a particular Unicode encoding for its strings should be exempt from the criticism that it does not have functionality dealing with converting between Unicode encodings.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
From: Edward Diener <eldiener@tropicsoft.com>
Okay. So that means people using std::wstring have to deal with converting to UTF-8 encoded std::string on their own. Sounds like a pain in Windows defaulted to use std::wstring in applications. :/
Converting between Unicode encodings should be a separate library anyway. Was there not someone working on such a cross-platform library for Boost ? What happened to it ? Was it scrapped because of possible Unicode support in C++0x ?
Accidentally (or not) there is a Boost.Locale library that I had submitted for a formal review is stuck in queue waiting for the formal review. It supports charset conversions and much more of Unicode handling. And accidentally (or not) it recommends using UTF-8 anywhere and not to use wide strings... http://cppcms.sourceforge.net/boost_locale/html/tutorial.html#1c383cd30b7c29... Artyom
On 12/14/2010 9:03 AM, Artyom wrote:
From: Edward Diener<eldiener@tropicsoft.com>
Okay. So that means people using std::wstring have to deal with converting to UTF-8 encoded std::string on their own. Sounds like a pain in Windows defaulted to use std::wstring in applications. :/
Converting between Unicode encodings should be a separate library anyway. Was there not someone working on such a cross-platform library for Boost ? What happened to it ? Was it scrapped because of possible Unicode support in C++0x ?
Accidentally (or not) there is a Boost.Locale library that I had submitted for a formal review is stuck in queue waiting for the formal review.
It supports charset conversions and much more of Unicode handling.
And accidentally (or not) it recommends using UTF-8 anywhere and not to use wide strings...
That's fine as long as you realize that it may not be the most common usage of Unicode for everybody ( such as in Windows programming ). I am looking forward to the review of Boost.Locale.
On Tue, Dec 14, 2010 at 8:48 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 12/14/2010 9:03 AM, Artyom wrote:
And accidentally (or not) it recommends using UTF-8 anywhere and not to use wide strings...
That's fine as long as you realize that it may not be the most common usage of Unicode for everybody ( such as in Windows programming ).
Or cross-platform programming with Qt and its (UTF-16?) QString. --DD
I would say that I'm going to release it under BSL for being it part of Boost as it has significant advantage to have library in Boost. But other then that I'd prefer to keep it LGPL meanwhile.
I wonder if you can legally do that, I mean changing the license of some LGPL code to Boost? emre
On Tue, Dec 14, 2010 at 6:45 PM, Emre Türkay <emreturkay2@gmail.com> wrote:
I would say that I'm going to release it under BSL for being it part of Boost as it has significant advantage to have library in Boost. But other then that I'd prefer to keep it LGPL meanwhile.
I wonder if you can legally do that, I mean changing the license of some LGPL code to Boost?
IANAL, but, last time I checked, if you own the copyright, you can release it under any license you want. ;) -- Dean Michael Berris deanberris.com
- Performance is the primary goal - make fastest possible SQL connectivity as possible - Transparent connection pooling support - Transparent prepared statements caching - Dynamic DB modules loading and optional static linking - Full and high priority support of FOSS RDBMS: MySQL, PostgreSQL, Sqlite3 - Support as many RDBMSs as possible via cppdb-odbc bridge - Simplicity in use - Locale safety - Support of both explicit verbose API and brief and nice syntactic sugar
I'm interested.
How is this different from SOCI and why should I use CppDB over SOCI?
Before I answer this question I'll tell that I'm familiar with SOCI, I used it for a while and I even had submitted several patches (for example dynamic backend loading implementation) to SOCI so I had reasons to implement something different then SOCI.
Lets start from clear advantages:
1. Transparent prepared statements caching - it gives with 0 effort significant performance boost. 2. Transparent use of connection pooling (only you need to add an option in connection string). 3. Full support of Sqlite3 and MySQL (SOCI's implementation of them is very poor) 4. Unicode Support in ODBC, i.e. you can use Unicode with MS SQL Server that does know speaks in UTF-8, SOCI does not support this.
Is that Unicode support integrated or do you rely on a separate Unicode library? If it came to a Boost submission, I believe separating this from your library would be a prerogative.
5. Support of both prepared and unprepared statements.
Sounds promising, indeed.
Few additional and less obvious points :
1. When last SOCI version was released? 2 Years ago, non-GIT soci version has lots of bugs and issues. So basically you need to use git version to use up-to-date SOCI. 2. SOCI was originally created as OCI wrapper and has some "Oracle quircks" - but this is a metter of tase.
Don't get me wrong, I like SOCI but I still think that my library provides some important added values that SOCI does not.
SOCI is non-GPL, so this is a clear advantage.
That said, I'd really not like to use code that is anywhere near the GPL in all my projects. If releasing under the Boost license is an option for you, I think that would be the single thing that I would expect for anything being submitted for review to Boost.
[...]
If I'm interested is another question, and the answer to that would be: if you can show that your library is better than SOCI, then I might be interested in using it -- but I'm not touching code that is anywhere near the LGPL or the GPL for that matter if I can help it.
I second this. GPL'ed code is viral and I'm afraid to get infected :-P Regards Hartmut --------------- http://boost-spirit.com
4. Unicode Support in ODBC, i.e. you can use Unicode with MS SQL Server that does know speaks in UTF-8, SOCI does not support this.
Is that Unicode support integrated or do you rely on a separate Unicode library? If it came to a Boost submission, I believe separating this from your library would be a prerogative.
cppdb's odbc driver uses both *A and *W API in same code explicitly without separating it. Also it is very important that odbc API allows to pass both wide and narrow strings in same API and what is even more important allows returning both narrow and wide strings is same query(!) So separation to "Unicode" and "non-unicode" version is meaningless (and actually requires) to mix both variants. The rest of the drivers are character set agnostic and use plain std::string. Artyom
Is that Unicode support integrated or do you rely on a separate Unicode library? If it came to a Boost submission, I believe separating this from your library would be a prerogative.
Ok... it seems that I didn't understand your questions, so ignore my previous answer. The only "Unicode Library" feature I use is the conversion between UTF-16 and UTF-8. So I just borrowed some code from boost.locale for simplicity, and it is about 100 lines of code so I don't think I should bother. Artyom
At Tue, 14 Dec 2010 08:53:15 -0600, Hartmut Kaiser wrote:
Is that Unicode support integrated or do you rely on a separate Unicode library? If it came to a Boost submission, I believe separating this from your library would be a prerogative.
Did you mean, "prerequisite?" A library author is not required to factor out and separately document and release every generally-useful implementation detail. Let's not make the hurdle higher than it needs to be. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, 14 Dec 2010 09:28:06 +0100, Artyom <artyomtnk@yahoo.com> wrote:
[...]
How is this different from SOCI and why should I use CppDB over SOCI?
[...]1. Transparent prepared statements caching - it gives with 0 effort significant performance boost. 2. Transparent use of connection pooling (only you need to add an option in connection string). 3. Full support of Sqlite3 and MySQL (SOCI's implementation of them is very poor) 4. Unicode Support in ODBC, i.e. you can use Unicode with MS SQL Server that does know speaks in UTF-8, SOCI does not support this. 5. Support of both prepared and unprepared statements.
Having seen Dean's question the next one which comes to my mind is: How is this different from OTL and why should I use CppDB over OTL? :) Boris
[...]
Having seen Dean's question the next one which comes to my mind is: How is this different from OTL and why should I use CppDB over OTL? :)
[...]
Boris
I hadn't used OTL too much and studied it too deep but, as first shot: CppDB supports MySQL, Sqlite3 and PostgreSQL natively and not via ODBC only. And BTW usually ODBC drivers are total... nightmare. Their implementation quality of many drivers is very low, because ODBC is over-complicated - for example ODBC's Sqlite3 driver in Debian Stable currently fails to handle transaction (it is clear driver's bug) Artyom
On Wed, 15 Dec 2010 08:06:21 +0100, Artyom <artyomtnk@yahoo.com> wrote: Hi Artyom,
[...]I hadn't used OTL too much and studied it too deep but, as first shot:
CppDB supports MySQL, Sqlite3 and PostgreSQL natively and not via ODBC only.
that's true - on Unix it requires setting up an ODBC infrastructure for these databases. This might be a K.O. criterium for developers. But then altogether the library supports so many databases and is actively maintained for such a long time that I would regard it as a strong competitor to any Boost database library. Boris
[...]
----- Original Message ----
From: Boris Schaeling <boris@highscore.de> On Wed, 15 Dec 2010 08:06:21 +0100, Artyom <artyomtnk@yahoo.com> wrote:
Hi Artyom,
[...]I hadn't used OTL too much and studied it too deep but, as first shot:
CppDB supports MySQL, Sqlite3 and PostgreSQL natively and not via ODBC only.
that's true - on Unix it requires setting up an ODBC infrastructure for these databases. This might be a K.O. criterium for developers. But then altogether the library supports so many databases and is actively maintained for such a long time that I would regard it as a strong competitor to any Boost database library.
I would recommend to stay away from ODBC unless you have to. ODBC drivers are usually total crap (sorry) - during testing CppDB and ODBC I had found so many flaws that I understand that ODBC is generally very bad way to go. The reason for this is very simple - ODBC API is overcomplicated, so writing a driver is very complex thing as a result too many drivers have very poor quality. As I mentioned Sqlite3 driver hadn't managed transactions, MS SQL/FreeTDS ODBC Driver for Linux does not support Unicode. And so on. So if you can avoid ODBC do it - its concept is great but the reality is not so. Artyom
----- Original Message ----
From: Boris Schaeling <boris@highscore.de> On Wed, 15 Dec 2010 08:06:21 +0100, Artyom <artyomtnk@yahoo.com> wrote:
Hi Artyom,
[...]I hadn't used OTL too much and studied it too deep but, as first shot:
CppDB supports MySQL, Sqlite3 and PostgreSQL natively and not via ODBC only.
that's true - on Unix it requires setting up an ODBC infrastructure for these databases. This might be a K.O. criterium for developers. But then altogether the library supports so many databases and is actively maintained for such a long time that I would regard it as a strong competitor to any Boost database library.
I would recommend to stay away from ODBC unless you have to. ODBC drivers are usually total crap (sorry) - during testing CppDB and ODBC I had found so many flaws that I understand that ODBC is generally very bad way to go. The reason for this is very simple - ODBC API is overcomplicated, so writing a driver is very complex thing as a result too many drivers have very poor quality. As I mentioned Sqlite3 driver hadn't managed transactions, MS SQL/FreeTDS ODBC Driver for Linux does not support Unicode. And so on. So if you can avoid ODBC do it - its concept is great but the reality is not so. Artyom
So does it worth the effort?
So before I do any steps forward may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily).
I'm interested in it. Is the ODBC-bridge already working? Regards, Barend
So does it worth the effort?
So before I do any steps forward may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily).
I'm interested in it.
Is the ODBC-bridge already working?
Yes of course, read this: http://art-blog.no-ip.info/sql/cppdb/support.html And this: http://art-blog.no-ip.info/sql/cppdb/odbc.html Artyom
Hi Artyom, On 14-12-2010 8:18, Artyom wrote:
Hello,
I have recently released a new SQL Connectivity library:
General -------
Documentation : http://art-blog.no-ip.info/sql/cppdb/ Mirror Docs. : http://cppcms.sourceforge.net/sql/cppdb/ Download : https://sourceforge.net/projects/cppcms/files/cppdb/
The download seems pointing to another distribution (dbixx-0.0.4.tar.gz containing 3 cpp files and not compiling) then the build instructions on the doc, this is confusing me. I see the odbc now. Regards, Barend
Documentation : http://art-blog.no-ip.info/sql/cppdb/ Mirror Docs. : http://cppcms.sourceforge.net/sql/cppdb/ Download : https://sourceforge.net/projects/cppcms/files/cppdb/
The download seems pointing to another distribution (dbixx-0.0.4.tar.gz containing 3 cpp files and not compiling) then the build instructions on the doc, this is confusing me. I see the odbc now.
Regards, Barend
You are trying to download the wrong file. Under CppCMS project there are much more then one file, dbixx is just another recently upladed file. Go to cppdb -> 0.0.1 and download cppdb-0.0.1.tar.bz2 right at the link I have you. Full link is http://sourceforge.net/projects/cppcms/files/cppdb/0.0.1/cppdb-0.0.1.tar.bz2... Artyom
On Tue, Dec 14, 2010 at 1:18 AM, Artyom <artyomtnk@yahoo.com> wrote:
I have recently released a new SQL Connectivity library:
Sounds great!
- Performance is the primary goal - make fastest possible SQL connectivity as possible
Some DBMS like Oracle support "array bind" operations (on insert and select) which greatly improve performance by limiting round-trips to the server. A quick look at the doc didn't seem to indicate any particular support for such a thing, which is pretty much essential for apps using Oracle as a repository of scientific data (as opposed to business shopping carts :). Have you considered this? Can it be supported in the future? Thanks, --DD
On Tue, Dec 14, 2010 at 1:18 AM, Artyom <artyomtnk@yahoo.com> wrote:
I have recently released a new SQL Connectivity library:
Sounds great!
- Performance is the primary goal - make fastest possible SQL connectivity as possible
Some DBMS like Oracle support "array bind" operations (on insert and select) which greatly improve performance by limiting round-trips to the server.
I'm aware of this feature as SOCI supports this and as Orcale's OCI is only one API (at least onle one I'm aware off) that supports this. CppDB has nothing special for this as it does not have (yet) Oracle specific backend (you still can use ODBC with Oracle). Also this kind of feature has many limitations on what can be fetched and stored and is very "OCI" specific so I do not do anything like that. I believe that during development of Orcale backend it is possible to bind some internal buffers for this and save them. And not I do not support this as it is very Oracle specific feature and have quite lots of problems. For example: - What do you do with varchar(10000) types how do you do bulk operations? Allocate for each entry huge amount of memory? Is this good? - What happens when you bind 100 strings when one of them is 10000 bytes length and others 10? Allocate 100x10000 bytes, I'm not aware if something better can be done but at least this is what SOCI does, and I beleive they do the best. - What amount of data do you allocate? You do not know in advance how many rows you fetch. This is exactly the kind of features that made SOCI's API too Orcale oriented and make it hard to use in other cases with other databases. So when writing Orcale backend it would be possible to do some optimizations for fetching data but they should be internal for the backend and not something generic. At least this is my opinion... Artyom
On Tue, Dec 14, 2010 at 1:22 PM, Artyom <artyomtnk@yahoo.com> wrote:
I'm aware of this feature as SOCI supports this and as Orcale's OCI is only one API (at least onle one I'm aware off) that supports this.
CppDB has nothing special for this as it does not have (yet) Oracle specific backend (you still can use ODBC with Oracle).
Also this kind of feature has many limitations on what can be fetched and stored and is very "OCI" specific so I do not do anything like that.
I wasn't using SOCI but directly OCI, and I don't remember any particular limitations compared to non-array binds.
And not I do not support this as it is very Oracle specific feature and have quite lots of problems.
Again, I'm not sure what you mean by "lots of problems". Once we understood how to do them (OCI is a very obtuse API), they worked just fine, and were much faster than the equivalent non-array binds. In fact Oracle array-binds were faster with a Win32 client talking to a remote 11g Linux64 server (on the LAN over Gb-ethernet) than the equivalent code against a local SQLite3 DB. With scalar binds SQLite was faster, but not with array-binds.
- What do you do with varchar(10000) types how do you do bulk operations? Allocate for each entry huge amount of memory? Is this good?
Well, we'd probably use a LOB datatype, in which case you only get the descriptor and later perform the IO on that descriptor (the new-in-11g SecureFile LOB columns had surprisingly good IO performance).
- What happens when you bind 100 strings when one of them is 10000 bytes length and others 10? Allocate 100x10000 bytes, I'm not aware if something better can be done but at least this is what SOCI does, and I beleive they do the best.
Somehow I vaguely remember that it could be avoided (there are different ways to do array binds), but I could be wrong. This stuff is more than 18 months old for me.
- What amount of data do you allocate? You do not know in advance how many rows you fetch.
We experimented with various sizes, but experimentatlly I noticed that once the combined amount of data in the arrays reached 32KB, that's when performance would level off for my particular win32 client (both client and server running 11g).
So when writing Orcale backend it would be possible to do some optimizations for fetching data but they should be internal for the backend and not something generic.
Striving for genericity and simplicity is good, as long as the API doesn't preclude doing more complex or proprietary things if the backend supports it. That's the reason we had to abandon OCCI, since it did not support many of the features OCI supported (XMLTYPE and objects in general, CQN, etc...) and didn't allow going under-the-hood to the OCI level when needed, to use what it (OCCI, the nice simple JDBC-like C++ API) didn't provide wrappers for. It's great to be able to use the nicely wrapped, typeseafe, syntax-sugar enabled, DBMS-agostic API when you can, as long as you can do proprietary things using the underlying API the back-end uses, on the same connection, the few times you really need to. I don't think what I describe above is incompatible with your stated goals either, and I respect the fact that you don't see it as something that needs to be supported in the generic API. If the back-end can be accessed, let me and others shoot ourselves in the foot when we really need to :) --DD
Hello All, Following my previous announcements of CppDB I want to inform you that I had changed the license to dual license BSL/MIT. MIT license option mostly to allow using GPL MySQL connector which does not have an exception for BSL. So I'm still asking for interest of Boost community. The library is not fully boostified (i.e. it does not placed in boost namespace and does not reuse some of boost code as it can) But this is something very simple to fix if there would be an interest. I'm quoting the previous details about the library as reminder what it was all about. Regards, Artyom Relevant Quote from previous message: ------------------------------------- I have recently released a new SQL Connectivity library: General ------- Documentation : http://art-blog.no-ip.info/sql/cppdb/ Mirror Docs. : http://cppcms.sourceforge.net/sql/cppdb/ Download : https://sourceforge.net/projects/cppcms/files/cppdb/ Features -------- - Performance is the primary goal - make fastest possible SQL connectivity as possible - Transparent connection pooling support - Transparent prepared statements caching - Dynamic DB modules loading and optional static linking - Full and high priority support of FOSS RDBMS: MySQL, PostgreSQL, Sqlite3 - Support as many RDBMSs as possible via cppdb-odbc bridge - Simplicity in use - Locale safety - Support of both explicit verbose API and brief and nice syntactic sugar What it is not: --------------- This is not ORM library and not supposed to be so. This is something similar to what JDBC gives to JDK and QtSql gives to Qt and more. Boost Interest -------------- [snip] So before I do any steps forward "Boostification" may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily).
08.01.2011 13:04, Artyom пишет:
So I'm still asking for interest of Boost community. I am absolutely sure that in Boost must be a library for SQL connectivity. And, IMHO, CppDB is well suited for this. I already tried it and I liked it.
- Denis
Boost Interest --------------
[snip]
So before I do any steps forward "Boostification" may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily).
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Extremely useful. I guess it needs to be boostified before it will pass a review though. - Christian
Boost Interest --------------
[snip]
So before I do any steps forward "Boostification" may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily).
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Extremely useful. I guess it needs to be boostified before it will pass a review though.
- Christian
I understand this procedure... But rather I would ask a question. When and how it would go to review. My current situation: - Boost.Locale - I currently maintain two versions: CppCMS's one and Boost one - because I need it and on the other side it is not in boost. - It is stuck in the review queue for about half a year. - I did big boostification effort and I pay for it. So should I do same mistake with CppDB and wait for another year to get it reviewed and maintain two versions? Good question. On the other hand I don't see any reason why it can't be reviewed this way. Artyom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 10 January 2011, Artyom wrote:
When and how it would go to review.
My current situation:
- Boost.Locale - I currently maintain two versions: CppCMS's one and Boost one - because I need it and on the other side it is not in boost. - It is stuck in the review queue for about half a year. - I did big boostification effort and I pay for it.
So should I do same mistake with CppDB and wait for another year to get it reviewed and maintain two versions?
Just to put out an idea: it seems to me developers tend to be more interested in submitting libraries than doing reviews or being review managers. Maybe boost could balance the scales by requiring library submitters to either be a review manager or review a couple submissions from others before their library can be accepted. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0reMcACgkQ5vihyNWuA4U3awCgm9C+CIp24+3S0IlQRxFsAFYq t2AAoOd672nX3mknaH1PAJXepwGR4JA6 =42BC -----END PGP SIGNATURE-----
... elision by patrick ... Just to put out an idea: it seems to me developers tend to be more interested in submitting libraries than doing reviews or being review managers. Maybe boost could balance the scales by requiring library submitters to either be a review manager or review a couple submissions from others before their library can be accepted. I always thought of review managers as needing a demonstrated higher level of understand of high level C++ and boost practices than someone
On 01/10/2011 01:23 PM, Frank Mori Hess wrote: that hasn't gotten a library accepted would have demonstrated yet. There are lots of people that have high levels of understanding that haven't submitted libraries, and some of those that have gotten libraries accepted might not be good review managers. (I swear no names come to mind! lol) It just seems the wrong connection to make. Patrick
On 1/10/2011 4:23 PM, Frank Mori Hess wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 10 January 2011, Artyom wrote:
When and how it would go to review.
My current situation:
- Boost.Locale - I currently maintain two versions: CppCMS's one and Boost one - because I need it and on the other side it is not in boost. - It is stuck in the review queue for about half a year. - I did big boostification effort and I pay for it.
So should I do same mistake with CppDB and wait for another year to get it reviewed and maintain two versions?
Just to put out an idea: it seems to me developers tend to be more interested in submitting libraries than doing reviews or being review managers. Maybe boost could balance the scales by requiring library submitters to either be a review manager or review a couple submissions from others before their library can be accepted.
I like your suggestion, and I believe Boost should do it. But I think the requirement should be to review a single submission, or be the review manager, within n months ( possibly 3 or 6 ) of submitting a library to Boost to go through the review process. But just as important, if Boost were willing to allow a longer time for a review and have more than one review going on at a time, I think the more leisurely pace of reviews would be better for all involved. I would even suggest that Boost could possibly have another mailing list/GMane NG just for reviews, so that people willing to focus on software to be reviewed could easily find what is being reviewed at any one time and contribute their own review more easily. As it is now, reviews are mixed in with many other comments on the mailing list/GMane NG and the time do do a review, as well as the responsibility of the review manager to keep track of a review, always seems rushed to me. I believe if it were otherwise more people would have the time to look at a library which might interest them and contribute to a review. As for being a review manager I agree with others that it takes a very good C++ programmer but if one is submitting a library to Boost that person has to be very good at C++ already. Perhaps also the responsibility of the review manager needs to be delineated. I am guessing that is on the Boost web site somewhere.
2011/1/10 Frank Mori Hess <frank.hess@nist.gov>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 10 January 2011, Artyom wrote:
When and how it would go to review.
My current situation:
- Boost.Locale - I currently maintain two versions: CppCMS's one and Boost one - because I need it and on the other side it is not in boost. - It is stuck in the review queue for about half a year. - I did big boostification effort and I pay for it.
So should I do same mistake with CppDB and wait for another year to get it reviewed and maintain two versions?
Just to put out an idea: it seems to me developers tend to be more interested in submitting libraries than doing reviews or being review managers. Maybe boost could balance the scales by requiring library submitters to either be a review manager or review a couple submissions from others before their library can be accepted.
+1 That's what I thought: http://lists.boost.org/Archives/boost/2010/05/166423.php Maybe it's time to refresh those ideas and to implement them instead of only discussing them. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
At Tue, 11 Jan 2011 02:56:47 +0100, Joachim Faulhaber wrote:
2011/1/10 Frank Mori Hess <frank.hess@nist.gov>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 10 January 2011, Artyom wrote:
When and how it would go to review.
My current situation:
- Boost.Locale - I currently maintain two versions: CppCMS's one and Boost one - because I need it and on the other side it is not in boost. - It is stuck in the review queue for about half a year. - I did big boostification effort and I pay for it.
So should I do same mistake with CppDB and wait for another year to get it reviewed and maintain two versions?
Just to put out an idea: it seems to me developers tend to be more interested in submitting libraries than doing reviews or being review managers. Maybe boost could balance the scales by requiring library submitters to either be a review manager or review a couple submissions from others before their library can be accepted.
+1 That's what I thought: http://lists.boost.org/Archives/boost/2010/05/166423.php
Maybe it's time to refresh those ideas and to implement them instead of only discussing them.
+1. What do the review wizards think of this idea? If they're on board, I don't think there's anything standing in the way. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
2011/1/11 Dave Abrahams <dave@boostpro.com>:
At Tue, 11 Jan 2011 02:56:47 +0100, Joachim Faulhaber wrote:
2011/1/10 Frank Mori Hess <frank.hess@nist.gov>:
So should I do same mistake with CppDB and wait for another year to get it reviewed and maintain two versions?
Just to put out an idea: it seems to me developers tend to be more interested in submitting libraries than doing reviews or being review managers. Maybe boost could balance the scales by requiring library submitters to either be a review manager or review a couple submissions from others before their library can be accepted.
+1 That's what I thought: http://lists.boost.org/Archives/boost/2010/05/166423.php
Maybe it's time to refresh those ideas and to implement them instead of only discussing them.
+1. What do the review wizards think of this idea? If they're on board, I don't think there's anything standing in the way.
And the vision that was planted in my brain Still remains Within the sound of silence . . . http://lists.boost.org/Archives/boost/2010/05/166423.php
On Jan 18, 2011, at 4:30 AM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
And the vision that was planted in my brain Still remains Within the sound of silence . . .
Right now it's suggested but not required that authors participate in reviews before submitting libraries. If this were required, and esp if authors had worked as review manager assistants, this would help make sure that they understand the review process before submitting (as well as helping to unlock the review queue).
2011/1/18 Gordon Woodhull <gordon@woodhull.com>:
On Jan 18, 2011, at 4:30 AM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
And the vision that was planted in my brain Still remains Within the sound of silence . . .
Right now it's suggested but not required that authors participate in reviews before submitting libraries. If this were required, and esp if authors had worked as review manager assistants, this would help make sure that they understand the review process before submitting (as well as helping to unlock the review queue).
+1, and thanks for helping to unlock the review process of Robert Kawulak's Constrained Value library as *the first* Review Manager Assistant of Boost :) Library contributors look at other libraries and their jorney through the review process anyway. So it'll be not too much additional effort to do the job as review manager assistant, which brings more benefits: * Submitter and RMA can be a team which may improve the library development. * The RMA establishes himself as someone who not only promotes his own project but also contributes for someone else. * The RMA thouroughly learns the requirements for Boost libraries and other aspects of the review process that will help with his own project. Ciao, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Right now it's suggested but not required that authors participate in reviews before submitting
From: Joachim Faulhaber 2011/1/18 Gordon Woodhull <gordon@woodhull.com>: libraries. If this were required, and esp if authors had worked as review manager assistants, this would help make sure that they understand the review process before submitting (as well as helping to unlock the review queue).
+1,
and thanks for helping to unlock the review process of Robert Kawulak's Constrained Value library as *the first* Review Manager Assistant of Boost :)
Indeed, Gordon couldn't constitute a better precedent for this idea putting a lot of valuable work into this. As a sidenote, I apologise for yet another period of stagnation with Boost Constrained Value. However, recently I am a bit less busy and work towards putting it into Boost at last. Best regards, Robert
2011/1/19 Robert Kawulak <robert.kawulak@gmail.com>:
Right now it's suggested but not required that authors participate in reviews before submitting
From: Joachim Faulhaber 2011/1/18 Gordon Woodhull <gordon@woodhull.com>: libraries. If this were required, and esp if authors had worked as review manager assistants, this would help make sure that they understand the review process before submitting (as well as helping to unlock the review queue).
+1,
and thanks for helping to unlock the review process of Robert Kawulak's Constrained Value library as *the first* Review Manager Assistant of Boost :)
Indeed, Gordon couldn't constitute a better precedent for this idea putting a lot of valuable work into this.
Because most of this process was communicated off-list, here is some information of what happened: Although Robert had a review manager and a successful review with a majority of yes votes, the project was trapped, because the review manager did not find time to summarize the discussion, sort out the conditionals and declare the final results. At BoostCon we discussed this case and the RMA ideas. Out of this discussion Gordon volunteered to do the job as a review manager assistant. He had expertise and had participated in the review and the related discussion. The idea was just to unburden the review manager, who suffered from time problems. So Gordon made an excellent summary of the reviews and the remaining controversial points. When the review manager still was not able to complete the job, the Review Wizards agreed to pass the RM resposibilities to Gordon, who finally declared the review result. The point here is that we moved the initiative from one competent person (seasoned booster) who was stuck for what ever reason, to another competent person (not so seasoned booster), who was motivated and interested to get the process moving again. The RM could have taken back the initiative but chose not to do so. So we took care that *a contribution was not discouraged by mere inaction.* To pass the initiative, the "action" to the motivated, the vibrant part of the boost community, without ignoring the experienced, or "established" part of the community, is the core of my ideas about introducing Review Manager Assistants.
As a sidenote, I apologise for yet another period of stagnation with Boost Constrained Value. However, recently I am a bit less busy and work towards putting it into Boost at last.
That's good to hear! Good luck with your project. Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Joachim Faulhaber wrote:
2011/1/19 Robert Kawulak <robert.kawulak@gmail.com>:
Right now it's suggested but not required that authors participate in reviews before submitting
From: Joachim Faulhaber 2011/1/18 Gordon Woodhull <gordon@woodhull.com>: libraries. If this were required, and esp if authors had worked as review manager assistants, this would help make sure that they understand the review process before submitting (as well as helping to unlock the review queue).
+1,
and thanks for helping to unlock the review process of Robert Kawulak's Constrained Value library as *the first* Review Manager Assistant of Boost :)
Indeed, Gordon couldn't constitute a better precedent for this idea putting a lot of valuable work into this.
Because most of this process was communicated off-list, here is some information of what happened: Although Robert had a review manager and a successful review with a majority of yes votes, the project was trapped, because the review manager did not find time to summarize the discussion, sort out the conditionals and declare the final results.
Hi, we will need another RMA for the review of Boost.Move as OvermindDL1 doesn't answer to the specific requests in this ML and personal email. If someone would take the time to make the summary of the review ... Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/SQL-Connectivity-Is-Boost-interested-in-C... Sent from the Boost - Dev mailing list archive at Nabble.com.
2011/1/19 Vicente Botet <vicente.botet@wanadoo.fr>:
Joachim Faulhaber wrote:
2011/1/19 Robert Kawulak <robert.kawulak@gmail.com>:
Right now it's suggested but not required that authors participate in reviews before submitting
From: Joachim Faulhaber 2011/1/18 Gordon Woodhull <gordon@woodhull.com>: libraries. If this were required, and esp if authors had worked as review manager assistants, this would help make sure that they understand the review process before submitting (as well as helping to unlock the review queue).
+1,
and thanks for helping to unlock the review process of Robert Kawulak's Constrained Value library as *the first* Review Manager Assistant of Boost :)
Indeed, Gordon couldn't constitute a better precedent for this idea putting a lot of valuable work into this.
Because most of this process was communicated off-list, here is some information of what happened: Although Robert had a review manager and a successful review with a majority of yes votes, the project was trapped, because the review manager did not find time to summarize the discussion, sort out the conditionals and declare the final results.
Hi,
we will need another RMA for the review of Boost.Move as OvermindDL1 doesn't answer to the specific requests in this ML and personal email.
If someone would take the time to make the summary of the review ...
The idea of a Review Manager Assistant role is not to be a rescuer for libraries whose review managers are missing in action in the first place. The proposal intends to accelerate the review process and to make the life easier both for submitters and for review managers and let people do the detail work who are willing and motivated anyway (the submitters of tomorrow). As for Boost.Move, fortunately Michael Caisse already stepped in as rescuer: 2010/12/23 Michael Caisse <boost@objectmodelingdesigns.com>:
I have chatted with OvermindDL1 on IRC and will be taking over compiling the results of the review. My intent is to complete the report by mid-January.
Best Regards - michael
Thank you Michael. It is good to know that there are people that are able to respond, when others vanish. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On 01/19/2011 12:43 PM, Joachim Faulhaber wrote:
2011/1/19 Vicente Botet<vicente.botet@wanadoo.fr>: <snip>
we will need another RMA for the review of Boost.Move as OvermindDL1 doesn't
<snip> As for Boost.Move, fortunately Michael Caisse already stepped in as rescuer:
2010/12/23 Michael Caisse<boost@objectmodelingdesigns.com>:
I have chatted with OvermindDL1 on IRC and will be taking over compiling the results of the review. My intent is to complete the report by mid-January.
Best Regards - michael
Thank you Michael. It is good to know that there are people that are able to respond, when others vanish.
Cheers, Joachim
I have been working with Ion and the Review Wizards. The result summary is nearly complete and will be published this week. michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
From: Frank Mori Hess <frank.hess@nist.gov> On Monday 10 January 2011, Artyom wrote:
When and how it would go to review.
My current situation:
- Boost.Locale - I currently maintain two versions: CppCMS's one and Boost one - because I need it and on the other side it is not in boost. - It is stuck in the review queue for about half a year. - I did big boostification effort and I pay for it.
So should I do same mistake with CppDB and wait for another year to get it reviewed and maintain two versions?
Just to put out an idea: it seems to me developers tend to be more interested in submitting libraries than doing reviews or being review managers. Maybe boost could balance the scales by requiring library submitters to either be a review manager or review a couple submissions from others before their library can be accepted.
Optimistic scenario. -------------------- Ok I want to submit a library so I need to be a reviewer or review manager, so lets review couple of libraries - remove the from the queue and then lets submit mine. However even with this very optimistic scenario you'll get a big problem: Catch 22 In order to submit review I have to review a 2-3 libraries first. According to "optimistic scenario" we would run out of libraries in review queue which is nice. But then in order to bring a new library you need to review others... Ooops - there are no! Realistic Scenario ------------------ 1. In order go "gain 2-3" reviews library submitters would be forced at least to review libraries... So they: a. Review libraries and submit reviews for domains that they are barely aware of them or not aware of them at all. This would lead to disaster. Think of somebody reviews cryptographic library or lock-free library and barely know the issues that can be there. Potentially new boost libraries would become total mess. b. Even today there is a big problem that most reviewers mostly concentrate on interface and documentation and barely look to the source code. I had read reviews of several libraries. Unfortunately almost nobody actually reads the code. Why? Because it is hard. Do you actually think that the quality of such "forced" reviews would be better? I think no, in fact the valuable reviews would be shadowed by the noise of these "unless-reviews" Good reviewer should be: - Knowledgeable of the problem domain - Interested in this library and using it in reality - Be able to understand how the library works from inside and to find some points that are actually problematic. 2. If new library submitters would volunteer to be review managers, they would likely now be too familiar with Boost internals and doughty if the quality of their management would be good. Bottom line ----------- This is not going to work. Back to the reviews problem --------------------------- When I started to develop boost.locale I hadn't had to support wide strings as they useless for my project I need Boost.Locale for - CppCMS. IMHO wide strings should die at some point. However keeping in mind that Boost users are using wide stings I created a full support of them in Boost.Locale. I did many things that I would not do them at all if I knew that Boost.Locale would be stuck in review queue despite the fact that it actually received several positive (and actually real high quality) reviews from the begging without actually having formal review. Now I have other smaller library that I think works very well and would fill important gap that boost Misses. Now: should I put the effort in Boostification of the CppDB library or users and can happily use it without being under boost namespace? I think yes. It is not the question of quality of the library or its usability it is just pragmatic question: Should I do lots of work and see its totally wasted? My $0.02 Artyom
Extremely useful. I guess it needs to be boostified before it will pass a review though.
- Christian
I understand this procedure... But rather I would ask a question.
When and how it would go to review.
My current situation:
- Boost.Locale - I currently maintain two versions: CppCMS's one and Boost one - because I need it and on the other side it is not in boost. - It is stuck in the review queue for about half a year. - I did big boostification effort and I pay for it.
So should I do same mistake with CppDB and wait for another year to get it reviewed and maintain two versions?
Good question.
Understood, that seems far from optimal. I kind of took for granted that libraries must be boostified before submitted for review, but does such a policy actually exist? The problem with lack of review managers has been going on for a while, how about this (already suggested maybe?): Split the review manager into two positions: * Responsible person 1 - Has knowledge on Boost's infrastructure, such as, tools, documentation, test and other best practices that should be followed by all libraries. Has enough background in boost to make a sound judgement when the review ends based on the discussions, without getting into the gritty details of the code or domain at hand. * Responsible person 2 - Has knowledge about the domain and will take more active part in guiding the library towards boost's standards in terms of generic programming etc.. I think it is difficult to find people that are comfortable in both the above, which I assume they have to be to act as a review manager? My cents, Christian
On Mon, 10 Jan 2011 20:27:54 -0600 Christian Holmquist <c.holmquist@gmail.com> wrote:
[...] The problem with lack of review managers has been going on for a while, how about this (already suggested maybe?): Split the review manager into two positions:
* Responsible person 1 - Has knowledge on Boost's infrastructure, such as, tools, documentation, test and other best practices that should be followed by all libraries. Has enough background in boost to make a sound judgement when the review ends based on the discussions, without getting into the gritty details of the code or domain at hand.
* Responsible person 2 - Has knowledge about the domain and will take more active part in guiding the library towards boost's standards in terms of generic programming etc.. [...]
+1. -- Chad Nelson Oak Circle Software, Inc. * * *
participants (22)
-
Artyom -
Barend Gehrels -
Boris Schaeling -
Chad Nelson -
Christian Holmquist -
Dave Abrahams -
Dean Michael Berris -
Denis Shevchenko -
Dominique Devienne -
Edward Diener -
Emre Türkay -
Frank Mori Hess -
Gordon Woodhull -
Hartmut Kaiser -
Joachim Faulhaber -
Klaim -
Maciej Sobczak -
Michael Caisse -
Patrick Horgan -
Robert Kawulak -
Sylvain Pointeau -
Vicente Botet