Author: Cinly OOI (---.medschl.cam.ac.uk)
Date: 04-22-09 09:47
rick reynolds wrote:
[snip]
> There have never been problems reported from this; you are the
> first to even mention it (that I know of). So if after all
> these years, the first person to bring it up calls it unlikely,
> what is the point of adding more complexity to the file names
> (we already have 6 extensions)?
>
I take your point in adding complexity. To me there is two ways of dealing with this problem. But background first:
All of us had the luxury of having a full computers where the scenario Coursolle mention is unlikely. However, I do know some micro-controllers where it will be a problem. They are less powerful.
> Note that not everyone uses the C library, so each code base
> would need to be changed, and for something not currently in
> the spec.
This conveniently bring me to the first way : I think another way to see it is "is it possible to make the C library (or Matlab library or python library) agnostics of extensions? If it is possible, it might be worthwhile, whether or not it is in the spec.
> There are many groups that have implemented this,
> it is a lot to tell them all to go change their code.
Most of the time adding extensions are quite a simple job. I wouldn't be too worry about asking them to change the code.
Even if the proposed extension point gets into the next NifTI specs, say NifTI2, everyone technically has the choice to opt out of NifTI2. Moreover, I cannot see any backward compatibility problem.
> Maybe you know of a systemic reason to allow that (such as mac
> filesystems jumping between cases, which they do to some
> degree).
> Do you know of something like that?
I cannot think of any systematic reason for allowing file system to jump between cases. In fact, I will say I will not allow any nifti library to jump between cases. After all, A.NII and a.nii are in my opinion two distinct different thing.
... which brings me to the second way of dealing with this problem:
It is probably easier for the person who encounter this problem to submit a patch to whichever library he is using to deal with the upper/lowercase issue.
Why? First, they are rare and it is difficult to work on the problem unless you have access to such a computer.
Second, the solution probably will have to be tailored to the computer architecture. And I do know that file system that does not follow the norm usually has a way to simulate the norm, e.g., (1) if all upper case is needed, you can write lower case into your program, then get it transparently converted to upper case when you do the reading or (2) I know of an old file system that does not support extension, so it will convert "stdio.h" to /h/stdio automatically.
|
|
