Client Platform? Server Platform?
I know not everyone is interested in getting a truckload of business intelligence about the users of their software. But for those of you who think the Desktop Analytics project is pretty cool, tell me a little bit about your development platforms.
Do you use Java or .Net to develop your desktop software? Or are you maybe using C++ with MFC or WxWidgets? Anyone selling desktop software built with Ruby or Python?
Do you have a server? Is it Windows or Linux? Do you have your own server, or do you use a VPS account? Or just a shared web server, with PHP/MySQL? Do you have permission to install your own software into your server environment? Are you already running a Java app server? Tomcat, or something else?
Whatever platforms people seem interested in are the ones I’ll focus on in my development, so express you preferences here!
June 15th, 2008 at 3:41 pm
Using Visual Studio, C++, proprietary GUI tools, no server.
June 15th, 2008 at 4:07 pm
I’m currently using WTL, but that is likely to change to C#/.NET 3.X for my next project.
Server side I’m using a shared LAMP host. I’d consider Wordpress as a benchmark for accessibility and ease of install.
June 15th, 2008 at 5:06 pm
Using java for a cross-platform development tool – an editor for UML sequence diagrams, check my link.
June 15th, 2008 at 6:13 pm
Desktop app is C++ with MFC. Server is a custom server built using C++ (also Windows only). Some day it might integrate with PHP but right now it uses simple templates.
June 15th, 2008 at 9:41 pm
Focus on one and you’re unnecessarily cutting people off. If I have learnt anything in my short time here, platforms are difficult to predict but every platform from now till the machines achieve sentience will need to interface with C.
Write a C dll which does all the work, export nicely to each language, profit. Feel free to use .NET behind the scenes though.
June 15th, 2008 at 10:05 pm
I’m planning on an embeddable library with C bindings, but I’m a little bit unsure about how to proceed.
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?
June 16th, 2008 at 2:07 am
Just write a generator yourself. Say its driven from a api.xml file:
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.
June 16th, 2008 at 2:08 am
Ugh… I pulled a noob: XML in blog comment.. Sorry!
June 16th, 2008 at 7:59 am
.NET 2.0 (C#).
Considering using Qt for the next product.
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.
June 17th, 2008 at 1:07 am
I use Java on both the client and server end.
I self-host for now under Windows (Tomcat) but plan on migrating to a dedicated server in the future as the need arises.
January 6th, 2009 at 7:00 am
+1 for providing a simple C interface.
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.