Web interface options¶
it is more likely better to use Java applets, for the bold-highlighted reasons below, and considering that the caveats at the bottom of the table can all be resolved. however, it may be faster to prototype a web form interface, as long as we keep in mind that we may want to switch to Java later.
note that this comparison refers specifically to Java applets. a Java desktop app will provide access to more OS commands and the user's filesystem, but does not have the important sandbox provided by the browser, which allows the user to trust that the applet will not damage their computer.
| + − − + |
*Java applet* or desktop app3 that queries the DB directly | HTML form w/ CGI1 backend (shell script2) that queries the DB |
| setup | + pro: easier: just distribute a Java applet, and use existing Postgres DB | − con: harder: needs a web server just to provide a GUI |
| client/server protocol |
+ pro: can use any client/server protocol (such as a direct database connection) | − con: must use form encoding (field=value&...) or XMLHttpRequest |
| client capabilities | + pro: as applet (browser-sandboxed): native access to full TCP/IP stack as desktop app (insecure): also interface to user's filesystem & most OS commands |
− con: only what browser provides (web form, XMLHttpRequest) |
| portability | + pro: every client offers the same API (the Java runtime) | − con: browsers' JavaScript APIs vary widely and require glue code |
| reusability | + pro: reusable: can be connected to any VegBIEN schema instance | − con: specific to BIEN: connected only to our VegBIEN DB |
| debugging | + pro: easier: typesafe Java classes4 and user community can fix client bugs themselves | − con: harder: mish-mash of JavaScript, HTML, CGI, etc. |
| speed | + pro: faster: each client makes changes to the Java UI locally | − con: slower: a central server has to render dynamic content for all clients, creating a bottleneck |
| web capabilities | − con: no support for external hyperlinks (but our interface doesn't need these) | + pro: hyperlinks handled by browser |
| test/debug cycle | − con: slower: need to recompile (but can automate the compiling) | + pro: faster: just edit script |
| UI programming | − con: harder: Java source code (but can create utils to structure this like HTML) | + pro: easier: HTML tags |
| client-side dependencies | − con: Java may not be preinstalled (but browser will prompt to download) | + pro: browser is preinstalled |
in either case, the API calls should always be available as PostgreSQL functions5, which can be invoked directly by a PostgreSQL client even in the absence of a GUI. this also makes it easy to add new API calls just by adding a PostgreSQL function.
1 CGI is probably the best server-side interface out there, because it doesn't integrate tightly with Apache and can be used with most web servers
2 because our most important scripts are shell scripts, so this would provide a more direct interface
3 this would provide access to the user's local filesystem, for them to upload/download flat files, etc.
4 counterpoints to Why isn't Java used for modern web application development?:
- "Twitter for example was built using Rails/Ruby but once it became unscalable, they migrated to the JVM [Java VM]."
- "running a .NET application with competent developers, the app just kept crashing every week. They finally converted it to Java and gained stability."
5 which are publicly-runnable and security-of-definer