[icedtea-web] Why use a separate basedir for plugin?

[Dr Andrew John Hughes]

On 14:27 Thu 28 Oct     , Deepak Bhole wrote:
> * Dr Andrew John Hughes <ahughes at redhat.com> [2010-10-28 12:39]:
> > On 10:02 Thu 28 Oct     , Omair Majid wrote:
> > > On 10/28/2010 09:38 AM, Dr Andrew John Hughes wrote:
> > > > On 18:31 Tue 26 Oct     , Omair Majid wrote:
> > > >> On 10/26/2010 06:18 PM, Deepak Bhole wrote:
> > > >>> * Omair Majid<omajid at redhat.com>   [2010-10-26 11:03]:
> > > >>>> Hi,
> > > >>>>
> > > >>>> I noticed that the plugin uses a different basedir (see
> > > >>>> JNLPRuntime.setBaseDir) from javaws. Is there a reason why?
> > > >>>>
> > > >>>> Since committing the deployment configuration patch, I have been
> > > >>>> working on integrating it into icedtea-web (I believe that ~/.netxrc
> > > >>>> is deprecated as of now). The deployment settings however, do not
> > > >>>> distinguish between plugin and javaws - whether in terms of the
> > > >>>> cache they use or which certificates are considered trusted. Hence I
> > > >>>> would like to make them both use the same certificates and cache
> > > >>>> (and possibly other things). Are there any reasons against doing
> > > >>>> this?
> > > >>>>
> > > >>>
> > > >>> Well, for one, they are 2 different things. We use the netx component
> > > >>> for embedding, but the plugin is still separate in terms of
> > > >>> functionality.
> > > >>>
> > > >>
> > > >> Right, but there is no reason they should not use the same
> > > >> proxy/cache/certificates, is there? Oracle JDK goes out of its ways to
> > > >> make them appear behave the same (including reading/parsing the mozilla
> > > >> configuration containing proxy settings in Java Web Start to get the
> > > >> same set of proxies the plugin would - I have not personally confirmed
> > > >> this, but the documentation says so).
> > > >>
> > > >>> How about putting everything in ~/.icedtea?
> > > >>>
> > > >>
> > > >> Sure, makes sense to me. My only question was about issues in having the
> > > >> plugin and netx share files.
> > > >>
> > > >
> > > > I thought we'd already decided to do this? :-)
> > > >
> > > 
> > > Really? I was not aware of that. As far as I know the plugin keeps its 
> > > files under ~/.icedteaplugin/ and netx keeps its files under ~/.netx/ 
> > > and we never decided to unify it.
> > > 
> > 
> > I can't seem to find the particular mail, but it was something to do with
> > a patch introducing the ~/.netx tree IIRC.
> > 
> > > >>> Speaking of deployement configuration, perhaps we should use
> > > >>> .java/deployement for that? If a user has previous deployment settings
> > > >>> from the Oracle JDK, they shouldn't have to re-do it just for
> > > >>> IcedTea/NetX.
> > > >>>
> > > >>
> > > >> That's the first thing I thought of, but I see a few potential issues
> > > >> with this. For one, the user can set values in this file which may cause
> > > >> Netx to and Web Start to clash. For example the cache hierarchy is quite
> > > >> different and one of them may overwrite/delete files the other creates.
> > > >> For another, the user may set values which may make sense in one and not
> > > >> another - for example setting a custom user.security.trusted.cacerts
> > > >> (which netx does not support) and then not allowing any security prompts
> > > >> for applications which appear untrusted. Such an application would work
> > > >> under Java Web Start but fail under netx.
> > > >>
> > > >> I am sure these issues can be ironed out, but for now we shouldnt ignore it.
> > > >>
> > > >
> > > > Unless this .java/deployment directory is openly specified, and that same specification
> > > > adhered to by the proprietary plugin, I would steer well clear.
> > > >
> > > 
> > > The only "specification" related to the ~/.java/deployment directory 
> > > that I can find is that it contains the deployment.properties file :/
> > > 
> > 
> > So steer well clear.
> > 
> 
> Well, the deployment.properties file is what I was referring to and it
> is the only thing I think we should share. It is supposed to be a simple
> <name>=<value> file.
> 

Well you could try reading it.  I wouldn't write to it.

Equally you could look at making use of system facilities such as the
HTTP_PROXY and HTTPS_PROXY environment variables and the libproxy library.

> Cheers,
> Deepak
> 
> > > > If the plugin was open source, then I wouldn't be so wary. But then, we probably wouldn't
> > > > even be writing our own then, would we?
> > > >
> > > 
> > > Heh. Good point.
> > > 
> > > Thanks,
> > > Omair
> > 
> > -- 
> > Andrew :)
> > 
> > Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> > 
> > Support Free Java!
> > Contribute to GNU Classpath and the OpenJDK
> > http://www.gnu.org/software/classpath
> > http://openjdk.java.net
> > PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> > Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8