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

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

Re: Resource confusion

Show all headers | View raw

On 12-01-31 04:43 PM, Martin Gregorie wrote:
> 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.
>  
Points. :-)

There are really 2 discussions here: where to put files, and how to read
them from where you put them. I was focusing initially more on the
reading bit, because I got the impression that's what the OP was really
wrestling with.

As far as the initial provision and bundling of configuration/data files
I'd be generally inclined to agree with you. And of course there isn't
any reason why a ream of "data" files that define different
user-selectable configurations couldn't be bundled in a JAR.

AHS
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

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