Re: [Openjnlp-devel] Arg...

[Christopher H. <he...@ez...>]

On Tuesday 26 March 2002 11:21 am, you wrote:
> On Monday, March 25, 2002, at 09:25 , Christopher Heiny wrote:
> [...]
>
>> development).  However, over the next few days I hope to be able to put
>> in
>> some effort, and plan to look into the following things (in part to
>> keep the
>
> Yikes. I just did a whole bunch of changes to the launching process to
> support command-line operation. I needed stuff in openjnlp-lib which I
> just got working last night. I'll be committing the changes later today.

OK, I'll hold off starting anything till you get that done.


>> 	- A "--gui/-g" command line option which will pop up the GUI and
>> open the
>> specified file/URL.  F'rinstance:
>> 		openjnlp --gui http://www.here.com/there.jnlp
>> Will pop-up the console, fetch the JNLP file, and then start the app.
>> The
>> GUI will hang around after the launch for further JNLP fun.
>
> The main entry point for OpenJNLP (org.nanode.app.OpenJNLP) is the
> GUI-based application. I believe the GUI coming up should be the default
> behavior, maybe a -nogui option makes more sense.

Well, right now the default is a GUI if no command line .jnlps are 
found; and
no GUI if there are .jnlp files on the command line.  This works nicely 
with
browser based JNLP launching -  casual users can just say "openjnlp %f" 
(or
whatever your browser wants) in their mime types, and the browsed app
launches 'by magic' with OpenJNLP remaining behind the curtain.  By
extension, I figured more advanced users who want both to launch an app 
and
the GUI would explicitly request that by saying "openjnlp --gui <JNLP>".
This has the additional benefit of not changing the current behavior of
OpenJNLP.


>
>> 	- When openjnlp is launched, look for one on the local machine
>> with the same
>> user (and under X, the same display), and have that one perform the
>> requested
>> tasks instead.
>
> This sounds like some IPC between running instances of OpenJNLP, how
> would this work? On Mac OS it is possible to send 'odoc' events to tell
> a running app to open a document, but how would this be implemented in
> java on Windows and linux?

I think the Jext text editor has a reasonable approach.  You do it with a
socket.  (see http://jext.sourceforge.org for Jext info; the method I'm
looking at is org.jext.JextFrame.loadInSingleJVMInstance(), see attached
file).  This method is invoked at tool start up, and (in a very 
simplified
overview) executes the following code:

		// authorization key is a cookie left in a well known place
		// by another instance of Jext
	if ( authorizationKey.exists() ) {
			// there might be another instance
		open a socket to localhost
		try to talk to the instance on the other end
		if ( success ) {
			tell the other instance what we want it to do
			exit
		}
		else {
				// he's not there
			delete the key
		}
	}

	create our own key
	stash the key in the well known place
	create an appropriate socket listener

Using a Socket is nice, since Sockets are platform independent and have 
been
in just about every JRE since the dawn of time.  I'm pretty sure they're 
in
J2ME, which helps if we want to make OpenJNLP embeddable.

I'd probably do some tinkering with it, both to make it a little more 
secure,
and to turn it into a Bean (or start it along that path) so that it can 
be
readily dropped into other apps.

					Chris