Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11684

Re: Resource confusion

Show all headers | View raw

On Tue, 31 Jan 2012 06:32:38 -0400, Arved Sandstrom wrote:

> On 12-01-30 10:45 PM, Martin Gregorie wrote:
>> On Mon, 30 Jan 2012 13:33:30 -0800, Roedy Green wrote:
>> 
>>> On Sat, 28 Jan 2012 17:47:48 +0000 (UTC), Novice <novice@example..com>
>>> wrote, quoted or indirectly quoted someone who said :
>>>
>>>> I'm having trouble figuring out the best way of obtaining existing
>>>> files for my program to use.
>>>
>>> I would put the read-only config files in a resource in a jar.  This
>>> means they can't get lost and they work even if the user is not
>>> capable of configuring his own files. They are also compact. They get
>>> updated automatically when you update the program.
>>>
>>> You problem then becomes, where to put the user's files.  JNLP lets
>>> you allocate some space with a hideous name, not really suitable for
>>> the user to insert things except via your game.  If he creates them
>>> with a text editor you might import them into that space or store the
>>> filenames (not files) in your own space so he can pick them off a menu
>>> by unqualified name, and you then go fetch them from the original
>>> locations as needed.
>>>
>> Same here: I'd put the defaults in the jar and, allow the user to put
>> overriding files in a master location and a one local to the user: if
>> it was a UNIX type system the master location would be /usr/local/etc
>> and the local location would be the hidden directory ~/.myapp and the
>> program would use a search something like this;
>> 
>>  List<String> config = new List<String>();
>>  config.add("~/.myapp/config.txt");
>>  config.add("/usr/local/etc/config.txt");
>> 
>>  boolean found = false;
>>  for (String s : config)
>>  {
>>    File cf = new File(s);
>>    if (cf.exists())
>>    {
>>      found = true;
>>      // use the configuration in cf
>>    }
>>  }
>> 
>>  if (!found)
>>    // use the default configuration held as a resource in the jar file
>>  
>> which lets the user's configuration take preference over the site
>> configuration in /usr/local/etc, which in turn takes precedence over
>> the jar file resource.
>> 
>> NOTE: this assumes that each configuration is complete.
>> 
>> Another way to do it is to read all three config files in the *reverse*
>> order (from jar file, then /usr/local/etc and finally from ~/.myapp)
>> with items read from an earlier file being overwritten by matching
>> items from a later file. This approach means that the config in the jar
>> file must give a default value for every item, but the site and user
>> configurations only need to provide values for items they want to
>> customise.
>>    
> This is the way I would do things too, in general, for a configuration
> file problem. One wants the average user to do as little as possible -
> preferably nothing - with a file system, because a large percentage of
> users don't get file systems.
> 
> I'll point out that the OP has a situation, as he/she has described it,
> where there are *several/many* input files that can configure _a_ game,
> and one of them is selected to configure a given game. This is not
> atypical for games with numerous scenarios. Although on the UI level it
> would certainly be desirable to present the user with a dropdown of
> selections, rather than a file chooser, the OP's problem seems to be one
> of reading *data* files, not one of reading a handful of true
> configuration files. And his actual questions start with the details of
> how best to _read_ a file, as I understand it.
>
Point, but the logic is still the same regardless of whether the file is 
a configuration or a (set of) data files, since he seems to be talking 
about a two level hierarchy of files where a local copy, if there is one, 
takes priority over one in the jar file.

You can see a situation in which the first run can only find the copy in 
the jar file and, in the course of the run, creates a modified local 
version which is what it should use for all subsequent runs. In that case 
I think my first suggestion would be the appropriate one and, again, 
would work regardless of whether the file contains a few items 
(configuration) or a lot (data).

One thing the OP may have missed is that, if the jarfile is intended to 
be handed to a site admin who then distributes it to a set of users, 
there may be a good case for providing a sysadmin tool that can extract 
the file(s) from the jar file, apply site-specific, site-wide 
customisations to them and put the result back in the jar file. Something 
like this can make the package a lot easier to install. 

Perhaps the most obvious example of this being a good idea would be if 
its a client-server app: the site-wide customisation tool would let the 
sysadmin put the site's server hostname etc. into the jar file before 
distributing it to the user community. The effect is that the app should 
'just run' on installation, making the users happy and saving the helldesk 
from an endless stream of "why can't X find the server?" queries.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Resource confusion Novice <novice@example..com> - 2012-01-28 17:47 +0000
  Re: Resource confusion Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-28 15:44 -0400
    Re: Resource confusion Lew <noone@lewscanon.com> - 2012-01-28 13:43 -0800
    Re: Resource confusion Novice <novice@example..com> - 2012-01-29 05:40 +0000
      Re: Resource confusion Lew <noone@lewscanon.com> - 2012-01-28 22:43 -0800
      Re: Resource confusion Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-29 13:24 -0400
  Re: Resource confusion Roedy Green <see_website@mindprod.com.invalid> - 2012-01-30 13:33 -0800
    Re: Resource confusion Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-31 02:45 +0000
      Re: Resource confusion Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-31 06:32 -0400
        Re: Resource confusion Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-31 20:43 +0000
          Re: Resource confusion Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-31 18:08 -0400
            Re: Resource confusion Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-31 23:01 +0000

csiph-web