Slashdot Mirror

  I'm not a lawyer myself, but I can say from experience that, when a lawyer finds a comment somewhere in the codebase that says "//these next two lines of code are MIT-licensed", steam shoots out of their ears and every developer in the company has to attend an all-day meeting about it.

This is absolutely common for many large commercial companies. I have several such companies as clients and getting any FOSS approved is a major process. In fact, one client preferred to send a check to one open-source project for a license even though legally it grants them no benefit. The project's website even says that the project "is in the public domain and does not require a license." Companies with large bankrolls will glady shell out thousands of dollars for some peace of mind.

http://www.hwaci.com/cgi-bin/l...

As a rule, I never used code directly from SO to avoid any licensing questions for my clients.

http://www.hwaci.com/cgi-bin/license-step1

of course the coder has to generate the WSDL - you're not suggesting you write a bunch of methods and expect the system to write your definitions for you?! I know there are systems that do this - but you still have to decorate your methods with the appropriate codes to make the generator work correctly.

Mind you, there are generators for .h files, and also for .cpp generators too - Visual Assist for VS does it as does Dehydra from Mozilla. And for years cproto has been around though that doesn't understand C++, only C.

quick google: http://www.hwaci.com/sw/mkhdr/makeheaders.html

works for c++, though I don't know how complete its functionality is for advanced C++ features.

They don't outright ban free/open source software, but they make you jump thru hoops to use it. Products like SQLite will sell you this one for a nice fee.

Richard Hipp (the main auther of SQLite) has said that his entirely open licence http://www.sqlite.org/copyright.html [sqlite.org] has caused problems to some companies, so he also has a commercial option http://www.hwaci.com/cgi-bin/license-step1 [hwaci.com]

It can be used as one wants but they also offer a license for the occasions like you've specified. Check out:

http://www.hwaci.com/cgi-bin/license-step1

Or sqlite: http://www.hwaci.com/cgi-bin/license-step1

I prefer the LEMON parser generator over yacc/bison. You can use LEMON with lex/flex or just roll your own scanner by hand (which is usually pretty easy anyways).

D. Richard Hipp created SQLite, which is now bundled with PHP5. He gives very detailed, personal responses to any questions on the SQLite mailing list. Very nice software and very good support. Thanks Hippster!

Well for those of you that don't like MySQL's restrictive licenses and want a quick little SQL db, PHP 5 is shipping with SQLite.

An interesting little database to say the least.

Here you go - sqllite.

Not sure if that's what you had in mind: it still uses SQL syntax to access the database. Alternatives would be something where you express relationships through code. I can't think of any way to do this that is cleaner than a join statement but I'd like to see what you had in mind.

However, sqllite is designed for exactly what you had in mind: embedding within a program you distribute. It supports exactly that subset of sql that I need for common programs and is very easy to use.

We are about to ship a cross platform Struts (java) based application and needed a simple, low maintenance, low overhead, cross-platform,truly free and fast sql engine.

It's probably too late for you, but other's making the same choice might also want to consider SQLite.

too big and complex, yet where basic SQL is a requirement

I've always liked MySQL, and continue to like the features they add to it. But if you're looking for a very basic SQL package, check out SQLLite.

It implements most of the SQL92 Standard and it is a library rather than a daemon.

Just something for those of you that don't like MySQL adding tons of features (stored Procs, triggers, etc).

Tcl/Tk proper is not a bad idea either. If one does not need the GUI part (Tk) then Tcl is relatively easy to integrate into a project, and is under 200k.

HowToEmbed from the Tcl Wiki is a good starting point, and MkTclApp may help.

Tcl has very consistent and simple syntax (although it can get rather confusing at times), and it is very simple to add new command into your application that are exposed via Tcl. One of the nicest aspects of Tcl is that is it seriously multi-platform.

Of course this all depends on the requirements: how powerful does the language need to be, what functions must it provide, what types do you need it to be able to handle, how small is "lightweight", etc.

This is great news that Compiere finally went DB-independent. As a Perl DBI/DBD user I find DB-independence almost a prerequisite for any software I use, almost as important as its free software license. (Still, I'd like to see SQLite support, my favorite DB-apps prototyping DB.) Now, when it doesn't depand on Oracle any more, I will probably finally install it in my lab. How is PostgreSQL and MySQL comparing to each other speed-, flexibility- and security-wise? Which one would you suggest using with Compiere? Is that true that with MySQL Compiere is faster for the most simple tasks, but anything more than that requires PostgreSQL, which is slower in the short run but better choice in the long run? I'm asking because I want to have a flexible and long-term maintainable solution, where performance (via the hardware budget) is one of the most important factors, and the best security is a must. Thanks.

SQLite is an open source (even public domain!) personal SQL-capable database. It lacks some features (like types other than strings and some SQL commands), but it's very useful for embedded databases.

SQLite is tiny, fast and ACID compliant. SQLite is a public domain embedded SQL database library. It is similar to BDB, but provides a complete SQL database.

Let us not forget about DBD::SQLite [cpan.org] — a DBI [cpan.org] (Perl [perl.org] Database Interface) driver which, not being a driver per se, includes a *full* SQLite distribution, so when one needs to use SQLite in a Perl program, one is only perl -W -MCPAN '-einstall"DBD::SQLite"' away from $dbh=DBI->connect(q(dbi:SQLite:dbname=dbfile)); which is truely amazing.

SQLite is tiny, fast and ACID compliant. SQLite is a public domain embedded SQL database library. It is similar to BDB, but provides a complete SQL database.

Let us not forget about DBD::SQLite [cpan.org] — a DBI [cpan.org] (Perl [perl.org] Database Interface) driver which, not being a driver per se, includes a *full* SQLite distribution, so when one needs to use SQLite in a Perl program, one is only perl -W -MCPAN '-einstall"DBD::SQLite"' away from $dbh=DBI->connect(q(dbi:SQLite:dbname=dbfile)); which is truely amazing.

SQLite is tiny, fast and ACID compliant. SQLite is a public domain embedded SQL database library. It is similar to BDB, but provides a complete SQL database.

SQLite is tiny, fast and ACID compliant. SQLite is a public domain embedded SQL database library. It is similar to BDB, but provides a complete SQL database.

This is a big deal, but (1) it appears to be an effort to light a fire under MySQL's licensing staff and (2) losing built-in MySQL support would not be all bad. It might cause PHP developers to give a little thought to their websites' back ends. This little SQLite database that is going into PHP 5 actually looks pretty neat. If a developer needs a more powerful back end, let him evaluate MySQL along with other alternatives. MySQL is increasingly profit-driven, while SQLite is good old-fashioned public domain open source, and deserves to be PHP's default database.

1. Small, lite-duty engine mostly for embedded or small-footprint apps. Subset of lanugage of #2.

SQLite: http://www.hwaci.com/sw/sqlite/

2. Full language, but lacking performance tuning. Mostly for development and smaller shops.

Firebird: http://firebird.sourceforge.net/

3. "Big-iron" version that has full language and performance tuning features.

SAPDB (almost, but still not up to Oracle's standards): http://sapdb.org/

If what you're searching is an OS HTML rendering engine, you should have a look at TkHtml. Altough it's written as a Tk widget, it shouldn't be too difficult to port it to another language since its written in C.

Sounds truly interesting. I suppose you don't have any links yet?

Sorry, no. The only thing that's close to release is a related framework component, STEnterprise (heh, let's see if we get sued for that name :-), which is intended to be a database independent object persistence layer (needed by some of the specialized managers in the MOM) intended to address the fact that Apple has mishandled EOF. That's due out at the end of the month, but it's not a major part of the STMOM framework, which is the core of Mary and MaryTool (the command line version).

Since there is growing interest in an updated user experience, I can provide a few links that I found inspirational in my work on Mary as a MOM.

• The Anti-Mac Interface got it right in 1996, but we didn't have the vast datastore on the desktop to make it worth it, or the processing power to make it happen.
• Liquid File System, insightful enough for me to say "screw it" to my own white paper and just implement the damn thing. :-)
• Placeless Documents, an excellent paper, as you might expect from Xerox PARC.
• SQLite, useful if you need to release software that would benefit from a database on a system that might not have one.
• Shore, which interestingly can have the object store accessible using directory navigation, addressing some migration issues.

If you just need SQL for one app, take look at SQLite. It's not client-server db, but SQL provided on top of gdbm files.

Most small projects does not need transactions, subqueries or locking. And to really take advantages of such features you need to have some good understanding of databases.

Lame excuse. Even SQLite
does transactions.

The survey is missing my choice - a browser that works, don't much care whose.

Over the few years on NetBSD, I've tried Chimera (surprisingly good), Arena (you call that a GUI?), Lynx, Netscape (remotely), possibly Amaya, Plume, w3/xemacs, probably others I don't remember... oh, yeah, kfm of course (It was wonderful until it quit showing GIFs and PNGs for a reason I've never figured out). I've been on pins and needles for Opera to come out; it came to be the only reason to use Winduhs and if it ultimately is only for Linux I may switch from NetBSD.

I finally got so desperate for a browser that I implemented one in TCL around TkHTML. I don't need Java or plugins or cookies or frames or all that junk - even CSS can go, I just need HTML/3.2, GIF (if permitted), PNG, JFIF, and a few standard protocols!! It's a pretty pass when what I can cobble together in a week is better for me than the other stuff... (PS: Hmmp. My forms usually work, but /. won't take 'em... I'll have to use Lynx.)

Why don't I work on Mozilla or kfm or Konqueror? I don't much feel like playing with DLing ±30 MB (you're lucky to have 28800 kb/s here) of C++ (I could never grok C++) and then try to fight to have my changes taken back.)