On Thu, 2009-11-12 at 07:23 -0600, jpsotta wrote: > The JCast WeirdX Java plugin would have to be installed inside each > known potential user of my system, that could be difficult, unless > this is an automatic download upon the connection request. However, a > pure Java solution may ease the solution of point 1, but I don't know > how ! > This is a Java application? In that case, why not install a Linux Java JVM and use that to run your application as a normal Linux application? It should 'just work' unless you're using JNI to execute Windows-specific code. OpenJava comes as standard with many distros and the Sun JDK is an easy install. This may make also simplify multi-user access, though that depends on the way your application is written: if it is written for use by only one user at a time, like most desktop applications, then you'll still need to run a copy for each user and arrange things so that that a user always accesses 'his' copy. > What is not clear for me is the relationships (and perhaps the > operational advantages) there are between this AP authorization > organization and my web site that resides just beside that. The > authorized user navigates also between my web pages, and my website > has already a registration system for specific member : so, is there > something I can reuse or put in a common box ? > The problem is one of avoiding many users connecting to an application that has no understanding of many users all interleaving requests to it. There are a few ways to solve this problem for a Java application, but all require some redesign, easiest approach given first: - run it via JWS (Java Web Start), which will let your application run on a user's PC. It downloads the JRE as needed together with the application and supporting jar files. This doesn't need any change to your code but does assume there are no common data files that you don't want to distribute. Web login would stop unauthorised downloads. - rewrite it as an applet. This will cause it to be run locally on your user's system. This needs minor changes to the application but also assumes there are no common data files that you don't want to distribute.Web login would stop unauthorised access to the applet. - rewrite it as a client/server system. The client stays on your host. Graphical clients are delivered to users via JWS or are applets. You'd need to add a login and authentication dialogue if the client is delivered via JWS. Web login would stop unauthorised access to the applet. - rewrite it to run under an application server, e.g. TomCat, and use your web server as the user interface. The rewrite might be quite extensive, but your web server can already deal with logins and user authentication. Martin
