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

[Omair Majid]

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.

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

Thanks,
Omair