1143276 - Repository with Add-Ons converted for SeaMonkey might be required

Status: RESOLVED WORKSFORME

(SeaMonkey :: Project Organization, enhancement)

Description

[Rainer Bielefeld]

The "Add-on Converter for SeaMonkey"
<http://addonconverter.fotokraina.com/>
makes available many additional Add-ons for seamonkey, for details see <http://forums.mozillazine.org/viewtopic.php?f=40&t=2834855>.
Tests are very promising. But I am afraid 
a) most SeaMonkey users do not know that possibility, 
b) procedure it is too complicated
c) feedback is too difficult and unorganized

So we need a repository for tested converted add-ons where we also can collect ratings (user experience), bug reports and so on.

d) I tried to upload a converted WOT add-on to the normal Mozilla 
   add-on-repositoriy, but by attempt became rejected.
   Any help appreciated, because IMHO SeaMonkey versions of the add ons
   would be the most elegant possibility.
e) An alternative for add-ons not containing binaries would be 
   sourceforge. Thoughts?
f) other alternatives?

With a little help I would be willing to do some work here, but first we will need a decision how to proceed.

This one is one of the  blockers "Bug 1138883 - (meta) Make SeaMonkey compatible Add-Ons more discoverable and convenient."

Comment 1

[Robert Kaiser]

I wouldn't say it's "required". That said, feel free to set up a site for it, I don't think the current SeaMonkey team can afford to put work into that.

Comment 2

[Rainer Bielefeld]

I've already started to work on a solution, probably I will create a sourceforge project for converted / adapted add-ons.
If there is a first useful result I will ask for help concerning marketing, may be uploading to Mozilla add-ons repository, ...

Comment 3

[Philip Chee]

You could also look at the Pale Moon Add-ons site currently being rewritten in PHP

Comment 4

[Philip Chee]

(In reply to Rainer Bielefeld from comment #2)
> I've already started to work on a solution, probably I will create a
> sourceforge project for converted / adapted add-ons.
> If there is a first useful result I will ask for help concerning marketing,
> may be uploading to Mozilla add-ons repository, ...
If the addon is already hosted on AMO, you'll need to change the GUID.

Comment 5

[Rainer Bielefeld]

Attachment: GUID COMPARISON

@Philip:
Good point. It seems that the automatic conversion adds a GUID. I am not familiar with GUID proceeding, so I can't tell whether that's ok.

Comment 6

[Rainer Bielefeld]

You can see efforts on <http://sourceforge.net/projects/seamonkeyaddons/>

For any problem directly related to that repository please open a ticket on sourceforge.net like <https://sourceforge.net/p/seamonkeyaddons/tickets/>

Comment 7

[lemon_juice]

It's a good idea with a repository of tested add-ons - I was also thinking about creating something more user-friendly but unfortunately time constraints don't allow me to taken on such a project so if you can and want to do something like this then great!

(In reply to Rainer Bielefeld from comment #5)
> Created attachment 8578654 [details]
> GUID COMPARISON
> 
> @Philip:
> Good point. It seems that the automatic conversion adds a GUID. I am not
> familiar with GUID proceeding, so I can't tell whether that's ok.
The automatic conversion adds SeaMonkey's GUID, which is not a problem. Philip was talking about the add-on ID (in yellow in your pdf) - each add-on has its own ID and AMO can't host multiple add-ons with the same ID. You would need to change it and also rename the add-on and if the licence permits then you could submit it to AMO. Not a very straightforward process so someone would have to modify and maintain such modified add-ons to be hosted on AMO.

(In reply to Rainer Bielefeld from comment #6)
> You can see efforts on <http://sourceforge.net/projects/seamonkeyaddons/>

This is nice, however I think in the long run static repositories of converted extensions require a lot of maintenance or become outdated. One of the benefits of the converter is that you can get the newest version of an extension and be up to date - or you can choose any of the older versions available on AMO's version history. With a static repository someone would have to monitor the extensions and publish new converted versions periodically. When the list grows large it becomes a lot of work to maintain - if you are willing to keep it up to date then of course it will work fine.

I think a better solution would be a separate web site for the repository and at the moment it could consist of a single table listing extensions. Each extension would link directly to the converter but a link to the original extension would also be useful. To the converter I could add the ability to specify extension's address in a URL param like this:

http://addonconverter.fotokraina.com/?url=https://addons.mozilla.org/en-US/firefox/addon/wot-safe-browsing-tool/

Then you could link extensions directly to the converter and people could get the latest converted version. Most probably I would not want such a URL to trigger conversion immediately (so as not to overload the server by random people and bots initiating the converter) but the extension's URL could be pre-filled and the user would have to press the button to convert and install. I could also hide the advanced preferences and (optionally) get rid of the final stage with file diffs and offer installation immediately. If a current converted version of an extension works with SM then it's >90% likely a future version also will so such links would be almost maintenance free and provide users with latest versions.

There are other things that would also be useful like user comments, ratings, sorting options (by name, date added).

Such a repository could also include modified extensions which require manual conversion and could link to them (for example to http://xsidebar.mozdev.org/modifiedmisc.html) - some could also be hosted in your static repository and people could send you (or post themselves) converted extensions. It would be useful to have a central listing of all available extensions.

Of course, these are only my ideas so whichever you think is worthwhile or possible for you to do then go ahead :). I can implement the URL param to the converter if you would like to use such links.

Comment 8

[Philip Chee]

(In reply to Rainer Bielefeld from comment #6)
> You can see efforts on <http://sourceforge.net/projects/seamonkeyaddons/>
> 
> For any problem directly related to that repository please open a ticket on
> sourceforge.net like <https://sourceforge.net/p/seamonkeyaddons/tickets/>

Remote XUL manager is already SeaMonkey compatible out of the box!

Comment 9

[Philip Chee]

(In reply to lemon_juice from comment #7)
> This is nice, however I think in the long run static repositories of
> converted extensions require a lot of maintenance or become outdated. One of
> the benefits of the converter is that you can get the newest version of an
> extension and be up to date - or you can choose any of the older versions
> available on AMO's version history. With a static repository someone would
> have to monitor the extensions and publish new converted versions
> periodically. When the list grows large it becomes a lot of work to maintain
> - if you are willing to keep it up to date then of course it will work fine.

Perhaps we could crowdsource the updates, get the involvement of community members who aren't coders or technical people.

Comment 10

[Rainer Bielefeld]

(In reply to Philip Chee from comment #8)
> Remote XUL manager is already SeaMonkey compatible out of the box!

Not for SM 2.33, see install.rdf:

<!-- SeaMonkey -->
    <em:targetApplication>
      <Description>
        <em:id>{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}</em:id>
        <em:minVersion>2.14</em:minVersion>
        <em:maxVersion>2.26.*</em:maxVersion>

> Perhaps we could crowdsource
Yes, I think for any solution (except with fix for Bug 1145026 and SM-"Compatibility Reporter 2.0.5" crowdsourcing will be required

Comment 11

[Rainer Bielefeld]

(In reply to Philip Chee from comment #8)
> Remote XUL manager is already SeaMonkey compatible out of the box!

I forgot to mention: of course I asked to make "Remote XUL manager" compatible with latest SMs in my add-on review March 15, 2015

Comment 12

[Rainer Bielefeld]

Currently I don't think that that is necessary.

Comment 13

[Tony Mechelynck [:tonymec]]

(In reply to Rainer Bielefeld from comment #10)
> (In reply to Philip Chee from comment #8)
> > Remote XUL manager is already SeaMonkey compatible out of the box!
> 
> Not for SM 2.33, see install.rdf:
> 
> <!-- SeaMonkey -->
>     <em:targetApplication>
>       <Description>
>         <em:id>{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}</em:id>
>         <em:minVersion>2.14</em:minVersion>
>         <em:maxVersion>2.26.*</em:maxVersion>
> 
> > Perhaps we could crowdsource
> Yes, I think for any solution (except with fix for Bug 1145026 and
> SM-"Compatibility Reporter 2.0.5" crowdsourcing will be required

Since this add-on does not require strict maxVersion checking, and has a minVersion > 2.1, it can profit from maxVersion auto-override. However AMO is stricter with SeaMonkey than it ought to be and it might tell you spuriously that this add-on is incompatible, or that you need Firefox > 10.0. Here are several workarounds:
• If you are presented with a button, "Install anyway", click it; or
• Download the add-on to your HD and install from there; or
• Install first the "AMO Browsing for SeaMonkey" extension, which is not available at AMO but at http://addonconverter.fotokraina.com/amo-browsing/ Use the highest available version of course. This add-on makes AMO better-behaved towards SeaMonkey.

Comment 14

[Rainer Bielefeld]

Currently not on agenda