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

[Dr Andrew John Hughes]

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? :-)

> > 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.

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?

> 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