Domain: daffodildb.com
Stories and comments across the archive that link to daffodildb.com.
Comments · 9
-
Re:Wow, that's a big fat ASS^H^HPI
Have a chip on your shoulder much? Most of what you're saying is simply incorrect. e.g. Java does not have half-a-dozen containers. Yes, the switch from the STL-inspired Vector to the more Java-ish ArrayList was annoying. Same with HashTable to HashMap. But beyond that, all those different containers you think you see are actually interfaces for wiring up complex functionality. Either that or completely different data structures with different performance characteristics. (Remember your CompSci courses?) The Java Collections package (which seems to be the only thing in Java you're remotely familiar with) provides enough functionality to write a complete database engine. Which, as a matter of fact, has been done quite a few times. (Sorry, ran out of words to link. Doh! Still more. Ah, to hell with it.)
The rest of the Java API is also not bloat. There are libraries for printing, crytography, sound, graphics, DOM, file I/O, text parsing, text formatting, text display, mathematics, directory interfaces (e.g. LDAP), distributed object systems, reflection, security, SQL database interface, logging, cross-platform preferences, regular expressions, ZIP/GZip support, accessibility, networking, the compiler, scripting engines, etc., etc., etc. Very little of the core API is redundant, with most of the (few!) redundancies being a result of the early days of Java before they moved away from the C++ style objects.
Nearly all of the post-1.0 APIs were done correctly the first time. Which means that the core Java API is actually quite slim for the amount of functionality it provides. And even then, there is a HUGE number of official expansion APIs for mail, multimedia codecs, network request/response handlers (e.g. servlets), 3D graphics, 3D sound, text-to-speech, speech recognition, telephony, SOAP, REST, USB, Bluetooth, scientific units, cross-platform desktop integration, Instant Messaging, P2P, and quite a bit more. And that's just the official JSR-approved expansions! The OSS and (bleh) commercial worlds are full of unofficial libraries to deal with nearly any problem you can come up with.
If you want bloat, stop looking at Java. Try compiling a few Linux apps sometime and tell me how many redundant libraries you come across. If you know what they all do (which is a miracle in of itself), compiling just ONE of those programs is enough to make a person blush with embarrassment. Not to mention that when a platform IS solidified (e.g. GNOME), it suffers from versionitis. (i.e. The constant need to upgrade your version of the libraries because this latest program no longer targets the version you just compiled. Or even worse, it requires a specific minor release, thus requiring you to have multiple minor releases of the library compiled and installed.) I won't even go into Microsoft's practice of inventing a new API for the same technology over, and over, and over again. (ODBC, DAO, ADO, JET, anyone?)
Now I happen to think that a lot of the choice that Linux offers is good. But don't point fingers at other platforms when there are more than enough examples of far worse situations close to home. -
Predictable
This really isn't a surprise. MySQL has both licensing problems, and feature problems in the competitive high-end markets. PostGreSQL has none of these issues, and can hold its own in a comparison with Oracle or SQL Server. These features led RedHat to PostgreSQL for their RedHat Database product, and I see little reason why they wouldn't attract Sun as well.
The only thing that slightly bothers me about their strategy is that Sun has been pushing their Java Systems hard. If they actually wanted to bolster that strategy, they'd have three major options for a Java Enterprise Database:
1. Cloudscape/Derby - This product makes the most sense from a technology and licensing perspective, but the fact that it was an IBM product (even though Cloudscape was originally a separate entity before being acquired) taints the software in such a way as to make Sun look bad if they used it.
2. Daffodil - This database is an excellent choice, but it would require the acquisition of another company, a move that the Sun shareholders might question. It would also bring quite a bit of flak in Sun's direction as Daffodil is an Indian company.
3. McKoi SQL - An excellent choice for a Java database, but lacks brand recognition. The feature levels and scalability of the database are still considerable questions. The GPL license also allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL.
As for the choice of Sunbird, I think it's simply a matter of "why not?" It's not like there's any particular leader in the market, and Sunbird plays nice with Firebird/Mozilla. -
Daffodil DB and Compiere (open source ERP)
Compiere an open source ERP project typically requires Oracle (although other DBs are supposedly in the works) but now you can also use Daffodil:
http://daffodildb.com/daffodil-compiere.html/
I haven't tried it yet... has anyone else?
-
phpBB icons?
Funny, they're using some of the phpBB icons for the menu on the top of their site:
The download icon:
http://www.daffodildb.com/images/download.gif
http://www.phpbb.com/images/b_downloads-over.gif
The forum icon:
http://www.daffodildb.com/images/forum.gif
http://www.phpbb.com/phpBB/templates/subSilver/ima ges/folder_big.gif
The buy icon (can't find this right now on phpBB's site, but I'm sure I've seen it there before):
http://www.daffodildb.com/images/buy.gif -
phpBB icons?
Funny, they're using some of the phpBB icons for the menu on the top of their site:
The download icon:
http://www.daffodildb.com/images/download.gif
http://www.phpbb.com/images/b_downloads-over.gif
The forum icon:
http://www.daffodildb.com/images/forum.gif
http://www.phpbb.com/phpBB/templates/subSilver/ima ges/folder_big.gif
The buy icon (can't find this right now on phpBB's site, but I'm sure I've seen it there before):
http://www.daffodildb.com/images/buy.gif -
phpBB icons?
Funny, they're using some of the phpBB icons for the menu on the top of their site:
The download icon:
http://www.daffodildb.com/images/download.gif
http://www.phpbb.com/images/b_downloads-over.gif
The forum icon:
http://www.daffodildb.com/images/forum.gif
http://www.phpbb.com/phpBB/templates/subSilver/ima ges/folder_big.gif
The buy icon (can't find this right now on phpBB's site, but I'm sure I've seen it there before):
http://www.daffodildb.com/images/buy.gif -
Re:It's not GPL, so I can't use it in my software.
I think Daffodil's One$DB which was recently open sourced at sourceforge under the LGPL license is a better bet look at http://www.sourceforge.net/projects/daffodildb/ These guys have also gives a comparison between their db and derby its interesting.. http://www.daffodildb.com/onedollardb-derby.html/
-
Re:Compiere is moving toward DB independence
Just a small correction for the community the correct web address for Daffodil DB is http://www.daffodildb.com/daffodil-compiere.html
It is running perfectly on compiere with much issues in the alpha stage
Cheers -
Re:Apples and oranges
But what are these alternatives you mention that are so much better suited for every possible scenario?
There is, of course, no tool that meets the needs of every possible scenario. Instead, there are tools that meet the needs of common scenarios. Most of what MySQL is being (improperly) used for could be easily replaced with PostgreSQL. Postgres offer similar performance, but takes a minor hit for data integrity. As a bonus, you gain sub-selects, stored procedures, SQL-92 compliance, and other features of a "real" SQL database.
MySQL is quite decent for something like a blog, but why even bother with a complete server in those cases? An embedded database such as Berkeley DB or HSQL (formerly Hypersonic) would provide better performance and would get rid of security issues inherent in running a complete database server.
In still other instances, SQL databases are misused for large object data storage. In many of these instances, an Object Database such as ObjectStore (or your favorite open source choice of the 1000+ options) will provide better performance, without sacrificing much in the way of database management. (Standard database management tools are usually insufficient for dealing with databases containing large amounts of LOBs.)
Basically, the choice in database and database technology should be carefully weighed against the application instead of saying "I know SQL and MySQL is 1337!"
Some other database options include:
DaffodilDB
SAP DB
FireBird DB
Cloudscape (Soon to be open source)
Xindice (XML Database)
ObjectDB
DB4O
Prevayler