Install plugin command should allow .zip files

[Jon Harman-3]

Hi,
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.

Jon

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

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

[Kenneth Sloan]

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

[Michael Schmid]

Hi Johannes,

hmmm, I would not consider it a bug that ImageJ recognizes .zip files as .jar.  For me, if's quite handy, also apart from the problem of distributing plugins via email:

If I have a few class files that I want to bundle with a plugins.config (to get the 'arg' strings for calling the plugins, and to get them into the correct menus), I simply mark them and zip them from the context menu, and then move the .zip into the plugins directory of ImageJ.

If ImageJ should adopt a strict interpretation of what a .jar file should look like, I would miss this!

Thus, this 'bug' makes life easier for me.

Michael
________________________________________________________________
On Apr 25, 2014, at 17:18, Johannes Schindelin 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

[ctrueden]

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

[dscho]

Hi Michael,

On Fri, 25 Apr 2014, Michael Schmid wrote:

> hmmm, I would not consider it a bug that ImageJ recognizes .zip files as
> .jar.  For me, if's quite handy, also apart from the problem of
> distributing plugins via email:
>
> If I have a few class files that I want to bundle with a plugins.config
> (to get the 'arg' strings for calling the plugins, and to get them into
> the correct menus), I simply mark them and zip them from the context
> menu, and then move the .zip into the plugins directory of ImageJ.
>
> If ImageJ should adopt a strict interpretation of what a .jar file should look like, I would miss this!
>
> Thus, this 'bug' makes life easier for me.

I understand that your current workflow uses this workaround. A work
around it is, though.

Have you ever considered writing your plugin in the Fiji Script Editor
(soon to be switched over to the even greater ImageJ2 script editor)?
There is a quite handy File>Make .jar command. It even has the File>Make
.jar (include sources) command.

As to mailing plugins... It has been all-too-common that spammers send out
attachments as .jar or .exe. That is why you have to use the workaround to
send a .zip.

But it really is a workaround, would you not agree?

The real problem you want to solve is that of distributing your plugin.
And by sending it via email, you definitely incur another problem: which
is the current version?

I would really like to ask you to check out the personal update sites. The
idea is that you have a simple, integrated way to work with ImageJ plugins
instead of having to resort to the Windows Explorer to bundle your plugin,
to resort to email to send the plugin, the recipient to resort to saving
the attachment, to resort to using the equivalent of the Windows explorer
to copy the plugin into the correct place, possibly removing incompatible
versions.

For the record, the design of the personal update sites does not preclude
at all using it in "plain" ImageJ 1.x (*nobody* uses plain ImageJ 1.x,
everybody installs this or that, and you can install the updater just as
well: just run File>Import>URL... and then import
http://update.imagej.net/bootstrap.js; for the moment it automatically
checks the ImageJ and the Fiji update sites, but that does not need to be
the case at all).

Also for the record, I would be delighted to have this in the "official"
ImageJ packages on http://imagej.net/, and it was my long-term plan
anyway, but we are still stuck at a very early phase in the
https://github.com/imagej/ij1-installer project, too early still to plan
anything as big as including a Javascript running the ImageJ updater.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan]

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

[dscho]

Hi Ken,

On Fri, 25 Apr 2014, Kenneth Sloan wrote:

> I disagree.

Well, by now it is obvious that you are really married to your idea and
try everything to defend it ;-)

However, I don't buy it. By your very reasoning, you would want ImageJ 1.x
to inspect every .tif file to figure out whether it is a macro file, or an
.exe file, or a .jar plugin, and then completely disregard the file
extension.

Sounds a bit ridiculous now, no?

:-)

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan]

If you can't discuss it politely, there's no point.  Goodbye.

And, yes - you do sound a bit ridiculous.

--
Kenneth Sloan
[hidden email]



On Apr 25, 2014, at 16:01 , Johannes Schindelin <[hidden email]> wrote:

> Hi Ken,
>
> On Fri, 25 Apr 2014, Kenneth Sloan wrote:
>
>> I disagree.
>
> Well, by now it is obvious that you are really married to your idea and
> try everything to defend it ;-)
>
> However, I don't buy it. By your very reasoning, you would want ImageJ 1.x
> to inspect every .tif file to figure out whether it is a macro file, or an
> .exe file, or a .jar plugin, and then completely disregard the file
> extension.
>
> Sounds a bit ridiculous now, no?
>
> :-)
>
> Ciao,
> Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Dear Ken,

On Fri, 25 Apr 2014, Johannes Schindelin wrote:

> On Fri, 25 Apr 2014, Kenneth Sloan wrote:
>
> > I disagree.

Please excuse the snarky tone of my mail. I have to admit that I found
your response quite offensive (I felt that my expertise was not taken
seriously ,but that I was instead treated as if I knew nothing about
*anything* computer development related).

Clearly, I should have refrained from writing that mail when still under
that impression.

I apologize,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html