Posted by
ctrueden on
URL: http://imagej.273.s1.nabble.com/Install-plugin-command-should-allow-zip-files-tp5007432p5007439.html
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