Mod parent up. This is indeed one of the central cancers here - that, regardless of the state of fair use during the life of a patent or copyright, the TERMS of those things extend so far into the future that by the time they are placed in the public domain the public may derive no real benefit from them other than idle historical curiosity.
`
- no decision or opinion in re Bliski has yet been handed down by the Federal Circuit since the en banc hearing, and:
- Professor Duffy is simply a lawyer offering an op-ed piece. While he is an informed member of the patent law community (he presented oral argument at that hearing) he does not work for the PTO, nor is he a federal judge. His opinions are just that - opinions.
So save the champagne or the kleenex; it's what the courts say that counts.
A word about unions- most of the posts here have mischaracterized them. A labor union does not necessarily mean time-based seniority or even any employee title or grade heirarchy at all; that is a detail of some particular unions.
Further, to "unionize" you do not need to form a new union from scratch, you can join an existing union and have them extend their charter to cover your field.
If you see unions strictly as a "blue collar" thing and don't think that unions are for technical and creative people, check out the Directors' Guild of America's basic agreement. Why aren't video game designers and video game directors represented by this union?
And you video game artists and programmers, why aren't you represented by IATSE? All of the digital special effects guys over at ILM are, and when _they_ go into crunch mode, it's _real_ crunch mode; and I'll tell you, they get _paid_.
This preoccupation with the "militia" reflects the classis mis-reading of the Second Amendment. One must consider 18th Century English usage.
Note that the Bill of Rights is more aptly the Bill of Individuals' Rights (as opposed to the Articles of the Constitution, which describe the organization of government and that government's powers over the individual).
The Second Amendment does not discuss the power of government to create a militia; rather, it discusses the rights of the individual in the face of a government that uses that militia to enforce its will.
The text of the second amendment is : "A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed." (bold-italics are mine). To translate into modern English: "Because the government has a military machine, the individual has the right to bear arms to resist that machine when necessary."
Thus, the second amendment does not provide the right to bear arms so that you can protect yourself from thieves and murderers, but to protect yourself from the Government if and when the next Hitler or Stalin comes to power and starts enacting policy at gunpoint.
--
As someone with an extensive cross-platform database development background I would warn you against ODBC if you're operating with large data sets and expect any sort of performance.
ODBC is fine for light duty queries (~100's, maybe 1000's of rows). On the order of 10K rows things begin to get dicey. When you get to 100K - 1M+ rows, go out for coffee. Twice.
Beyond performace, ODBC is a cumbersome beast to use in a C++ application. Clearly it's a case of a heavily over-engineered solution without a good understanding of the problem. Writing an ODBC driver is even worse (I've written several) -- the spec is the size of a phone book. Bottom line, stay away from it if at all possible, unless you're relying on some other abstraction layer that keeps the ODBC API away from you.
I have used Rogue Wave's DBTools.h++ (now called SourcePro DB) package and found it to be terrific, provided that they have a "native" (i.e. non-ODBC) library for all of the databases on your requirements list. They do not have a mySQL native library, but you may wish to consider using SourcePro DB anyway and writing your own mySQL native library. Rogue Wave sells their source code (or at least they used to), so you can purchase it for, let's say, the Informix library and use it as a guide for your own implementation.
If you don't have any CapEx or budget is otherwise an issue, then don't discount SQLAPI++. Based on what you asked for, the only thing it doesn't appear to do that you need is SQL Server on Linux - it looks like it does everything else. Consider writing that piece. (Perhaps if you contribute the code back to the SQLAPI folks they'll waive the shareware fee and even help you with the effort.) You may luck out and not even have to, since SQLAPI++ supports Sybase. Microsoft SQL Server is essentially Sybase -- they bought the System 10 codebase. Admittedly over the years the two products have diverged, but it's quite possible that they both still support the same networking layer. Worth a try before you start writing code.
Lastly and in a different direction, I have evaluated the "write in java compile with gcj" option, and have not found gcj sufficiently mature for this to be done purely. If you can get away with it, I've had good success writing quite performant database code in Java using JDBC and then hooking it up to the C++ app via JNI. By parameterizing the database connectivity in a properties file, you can thus switch databases just by changing a text file. I've used this technique successfully when I had to connect to MySQL, Oracle and SQL Server all with the same app, and it only took a day or two to write all of the code.
Slashdot Mirror
Please mod parent up; at least as informative (and far more useful to most of us) when compared to GP.
Mod parent up. This is indeed one of the central cancers here - that, regardless of the state of fair use during the life of a patent or copyright, the TERMS of those things extend so far into the future that by the time they are placed in the public domain the public may derive no real benefit from them other than idle historical curiosity.
`
- no decision or opinion in re Bliski has yet been handed down by the Federal Circuit since the en banc hearing, and:
- Professor Duffy is simply a lawyer offering an op-ed piece. While he is an informed member of the patent law community (he presented oral argument at that hearing) he does not work for the PTO, nor is he a federal judge. His opinions are just that - opinions.
So save the champagne or the kleenex; it's what the courts say that counts.
P.S. - P.J. and the GrokLaw folks have been discussing this.
Expect Tiger 10.4.1 mid- to late-May
Further, to "unionize" you do not need to form a new union from scratch, you can join an existing union and have them extend their charter to cover your field.
If you see unions strictly as a "blue collar" thing and don't think that unions are for technical and creative people, check out the Directors' Guild of America's basic agreement. Why aren't video game designers and video game directors represented by this union?
And you video game artists and programmers, why aren't you represented by IATSE? All of the digital special effects guys over at ILM are, and when _they_ go into crunch mode, it's _real_ crunch mode; and I'll tell you, they get _paid_.
Note that the Bill of Rights is more aptly the Bill of Individuals' Rights (as opposed to the Articles of the Constitution, which describe the organization of government and that government's powers over the individual).
The Second Amendment does not discuss the power of government to create a militia; rather, it discusses the rights of the individual in the face of a government that uses that militia to enforce its will.
The text of the second amendment is : "A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed." (bold-italics are mine). To translate into modern English: "Because the government has a military machine, the individual has the right to bear arms to resist that machine when necessary."
Thus, the second amendment does not provide the right to bear arms so that you can protect yourself from thieves and murderers, but to protect yourself from the Government if and when the next Hitler or Stalin comes to power and starts enacting policy at gunpoint.
--
ODBC is fine for light duty queries (~100's, maybe 1000's of rows). On the order of 10K rows things begin to get dicey. When you get to 100K - 1M+ rows, go out for coffee. Twice.
Beyond performace, ODBC is a cumbersome beast to use in a C++ application. Clearly it's a case of a heavily over-engineered solution without a good understanding of the problem. Writing an ODBC driver is even worse (I've written several) -- the spec is the size of a phone book. Bottom line, stay away from it if at all possible, unless you're relying on some other abstraction layer that keeps the ODBC API away from you.
I have used Rogue Wave's DBTools.h++ (now called SourcePro DB) package and found it to be terrific, provided that they have a "native" (i.e. non-ODBC) library for all of the databases on your requirements list. They do not have a mySQL native library, but you may wish to consider using SourcePro DB anyway and writing your own mySQL native library. Rogue Wave sells their source code (or at least they used to), so you can purchase it for, let's say, the Informix library and use it as a guide for your own implementation.
If you don't have any CapEx or budget is otherwise an issue, then don't discount SQLAPI++. Based on what you asked for, the only thing it doesn't appear to do that you need is SQL Server on Linux - it looks like it does everything else. Consider writing that piece. (Perhaps if you contribute the code back to the SQLAPI folks they'll waive the shareware fee and even help you with the effort.) You may luck out and not even have to, since SQLAPI++ supports Sybase. Microsoft SQL Server is essentially Sybase -- they bought the System 10 codebase. Admittedly over the years the two products have diverged, but it's quite possible that they both still support the same networking layer. Worth a try before you start writing code.
Lastly and in a different direction, I have evaluated the "write in java compile with gcj" option, and have not found gcj sufficiently mature for this to be done purely. If you can get away with it, I've had good success writing quite performant database code in Java using JDBC and then hooking it up to the C++ app via JNI. By parameterizing the database connectivity in a properties file, you can thus switch databases just by changing a text file. I've used this technique successfully when I had to connect to MySQL, Oracle and SQL Server all with the same app, and it only took a day or two to write all of the code.