Posted by
Kenneth Sloan on
URL: http://imagej.273.s1.nabble.com/Install-plugin-command-should-allow-zip-files-tp5007432p5007442.html
There's a difference between "workaround" and "general principle".
What I see here is one type of workaround being elevated to a general principle
and being imposed on others.
Again: be conservative in what you generate...and liberal in what you accept.
And still again - if it is necessary to know the NAME of the file in order to
understand it, that's a bug in the design of the file format. Instead of embracing
this kind of restriction - we should work around it AND NOT EXTEND IT FURTHER.
As near as I can make out, there is no reason why you can't name a .jar file using
any name you want - and still have ImageJ figure out what to do with it. As long as
that is the case, then the design of the file format passes muster - and so do
the rules. What I hear being proposed (and/or implemented in some places, but not
others) is to IMPOSE a restriction that is not technically necessary, simply because
...well, I'm at a loss to understand WHY someone would want to do this.
In the cases where you are forced to deal with badly designed file formats not
of your making - you can be excused for using the file name as a hint. Only,
please recognize this as a bug and not a "feature".
I'm no stranger to the weird things that go on in file format design - I designed my first
image file format in 1979. At one time, I maintained a suite of programs that could read and
write nearly every image file format then in existence (back when dinosaurs roamed the Earth).
File naming conventions are useful when you need to go from a collection of file names
to a set of actions on those file names. That's useful - but in general I would prefer
to use the directory structure to keep files sorted by type.
MY PREFERENCE for handling "all .jar files in a given directory" is something like:
a) look at *every* file in the given directory
b) check to see if it happens to be a vaild ".jar" file
c) silently pass over those that fail the test in b)
This would be maximally convenient for the USERS and minimally inconvenient for the
implementors. Which is MY goal.
Your milage may vary.
--
Kenneth Sloan
[hidden email]
On Apr 25, 2014, at 13:14 , Curtis Rueden <
[hidden email]> wrote:
> Hi Ken,
>
>> In my opinion, no program should make an accept/rejection decision
>> based on the NAME of a file - only on the content. If the content is
>> not sufficient - then THAT bug should be squashed.
>
> I agree that detecting whether a .zip file is a valid Java archive is
> straightforward as well as convenient, so I see little downside in
> supporting it.
>
> However, in general I disagree that "no program should make an
> accept/rejection decision based on the NAME of a file." Having worked on
> Bio-Formats for many years, which supports ~130 file formats, I can say
> from experience that sometimes, the file extension is the *only* reliable
> information you'll have to go on for classifying file type. Not every
> format employs things like magic identifier bytes. Take .tif versus .raw
> for instance -- the same byte stream may be valid for both, but ImageJ
> would interpret the contents very differently depending on that file
> extension.
>
>> Not EVERYONE uses the same file naming conventions that you have been
>> exposed to.
>
> Actually, at this point I think we do, at least for all modern and popular
> platforms. Even Macs have dropped their "no file extensions necessary"
> shenanigans in favor of the DOS-style three-letter extensions.
>
> Regards,
> Curtis
>
> P.S. Of course, for some formats the file extension alone is also
> insufficient. In general, the only way to be 100% sure a file is a valid
> example of a particular file type is to fully read the file. But
> pragmatically, it is almost always enough to parse certain header bytes,
> etc., rather than reading every byte of the file...
>
>
> On Fri, Apr 25, 2014 at 10:44 AM, Kenneth Sloan <
[hidden email]> wrote:
>
>> I disagree. The tendency to rely on suffixes to provide meta-information
>> about file type is
>> a most unfortunate one. There are, I'm sure, ways to detect whether or
>> not a given file
>> is a valid ".jar" file - no matter what the filename is.
>>
>> "Be conservative in what you produce, but liberal in what you accept" is
>> the watchword
>> for good protocol design. Using suffixes as a hint is OK. Rejecting
>> perfectly good
>> input because of an ironclad naming system is not.
>>
>> In my opinion, no program should make an accept/rejection decision based
>> on the NAME
>> of a file - only on the content. If the content is not sufficient - then
>> THAT bug should be squashed.
>>
>> All of the above is even more important when trying to deliver content
>> across many different
>> platforms and operating systems. Not EVERYONE uses the same file naming
>> conventions
>> that you have been exposed to.
>>
>> --
>> Kenneth Sloan
>>
[hidden email]
>>
>>
>>
>> On Apr 25, 2014, at 10:18 , Johannes Schindelin <
>>
[hidden email]> wrote:
>>
>>> Hi Jon,
>>>
>>> On Fri, 25 Apr 2014, Jon Harman wrote:
>>>
>>>> I have changed the .jar suffix for my plugin to .zip when emailing it
>>>> since many email providers will not accept .jar files. This works fine
>>>> and is recognized as a plugin by ImageJ. So the plugin installer should
>>>> recognize .zip.
>>>
>>> While it is true that every .jar file is also a .zip file, the converse
>> is
>>> not true.
>>>
>>> Therefore, what you ask for would introduce a bug. (That ImageJ
>> recognizes
>>> ..zip files as .jar files is a very notable bug, too.)
>>>
>>> The correct way to resolve your issue is for the recipients of said mail
>>> to rename the file back.
>>>
>>> Ciao,
>>> Johannes
>>>
>>> --
>>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>
>> --
>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html