I wouldn’t worry about creating an OO facade via the DLL, in fact I would avoid that and let people creating any wrappers handle that.

My app is in python, but I could live with a simple C interface. +1 if there was a way to use the embedded library from a Mac.

I used a tool called ’swig’ (http://www.swig.org/) when I created python (and a co-contributer created Perl) wrappers for the Fast-Light Gui toolkit. One set of files generates wrappers for many languages:

* Tcl 8.0 and newer versions.
* Python 1.5 and newer.
* Perl 5.003 or newer.
* Guile 1.3.4 and newer.
* Java JDK 1.1 and newer.
* Ruby.
* Mzscheme.
* PHP
* Objective Caml (Ocaml) and Pike
* C# and the Chicken scheme
* Allegro CL and Modula-3
* Lua, CLISP and Common Lisp with UFFI
* Common Lisp with CFFI
* R
* Octave
* a JavaScript module for SWIG
* D programming language
* SWIGEiffel for Eiffel.

So you could probably have a big benefit on your hands for folks if you provided a solid swig interface file with your client library.

I’m no longer interested in the other languages, so I now use a tool called Pyrex for creating python modules from C libraries because it is simpler to use.

I self-host for now under Windows (Tomcat) but plan on migrating to a dedicated server in the future as the need arises.

Servers:
1. A bunch of local servers (Windows 2003, Solaris 10, Fedora 9, openSUSE 10.3) on VMWare Server and Microsoft Virtual Server).
2. Web hosting account with VERIO. Cannot install custom .exe’s.
3. Virtual Server account (with full Admin privileges) with VPSLAND. Here, I *can* install my custom executables, – using Remote Desktop.

No, no Java yet. Might have to switch the current DBMS to Sun JavaDB (or, IBM Cloudscape, or Apache Derby) for the next release: if so, will need Java runtime then.

Some doc here

Some doc here
Some doc here
…

…

So given the above Foo class, your C-API would look like:

// _1 b/c number of parameters (C doesn’t allow overloading)
foo*
new_foo_1(int something);

void
delete_foo(foo * fooptr);

int
foo_bar_1(foo * fooptr, int some_param);

Should take you all about one day to write per language you want to target. Try C++ to start. I’ve done this too many times to count.

I think most users of high level (and primarily object-oriented) languages will balk at an API that consists entirely of free functions. So the language-specific wrappers will almost certainly create an object-oriented facade around those functions.

But I’m not really sure how to do that. Anyone have any tips? Maybe links to some articles describing a good set of techniques?

Write a C dll which does all the work, export nicely to each language, profit. Feel free to use .NET behind the scenes though.

Server side I’m using a shared LAMP host. I’d consider Wordpress as a benchmark for accessibility and ease of install.