692971 - New table for guids + appversion shown in search/guid

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[Jeff Balogh (:jbalogh)]

The table should be a guid + a link to an app min/max. So that's actually two tables since ApplicationsVersions requires a Version in the middle.

It only needs to show up in search/guid and the admin tool to manage these guids so there's no need to hack this into the Addon table. clouserw has promised as much.

https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible
"AMO needs to return compatibility information about add-ons, even non-hosted ones, in its GUID search API responses. "

Comment 1

[Jeff Balogh (:jbalogh)]

bug 692972 suggests this will be guid => versions => app version, so maybe the existing Version table will get reused.

Comment 2

[Jeff Balogh (:jbalogh)]

And a field for the add-on name for bug 543793.

Comment 3

[Justin Scott [:fligtar]]

From irc it sounds like we need to iron out some details here. The way I was thinking of it and tried poorly to detail in the wiki page is that:

* add-on metadata pings (search/guid) should have a new compatibility section. We already ask AMO about all installed add-ons this way, so it makes sense to go here as opposed to sending hundreds of millions of additional update pings to AMO.

* we will only display a compatibility section if we have compatibility override data

* override data should be a GUID and add-on version range along with the overriding maxVersion compatibility information. For example, if we find out that versions 1.5 - 2.0 don't work with Firefox 6, we might say:
  versions: 1.5 - 2.0
  apps:
    firefox: 5.*

* it's possible an add-on would have multiple version ranges, but hopefully that would rarely be needed.

Thoughts?

Comment 4

[Jeff Balogh (:jbalogh)]

unfocused: can you comment here or in the wiki on 1) where firefox wants to find this 2) what format you're looking for? It sounds like we're moving towards [version range] => [app range], in which case something like this might work:

<remote_addon>                                                                            
  <guid></guid>
  <name></name>                                                                 
  <version_ranges>                                                              
    <version_range>                                                             
      <min_version></min_version>                                               
      <max_version></max_version>                                               
      <compatible_applications>                                                 
        <application>                                                           
          <name></name>                                                         
          <application_id></application_id>                                     
          <min_version></min_version>                                           
          <max_version></max_version>                                           
          <appID></appID>                                                       
        </application>                                                          
      </compatible_applications>                                                
    </version_range>                                                            
  </version_ranges>                                                             
</remote_addon>

The compat_applications part is taken from the current guid search API. The version_ranges part is my own doing, and I feel pretty bad about all the XML in there.

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(Cross-posting from IRC)

Looks good. Though would *much* prefer <addon type="remote"> rather than <remote_addon>

Comment 6

[Jeff Balogh (:jbalogh)]

(from :unfocused over email)

<addon_compatibility id="XXX" hosted="true|false">
 <guid>XXX</guid>
 <name>XXX</name>
 <version_ranges>
   <version_range type="compatible|incompatible">
     <min_version>XXX</min_version>
     <max_version>XXX</max_version>
     <compatible_applications>
       <application>
         <name>XXX</name>
         <application_id>XXX</application_id>
         <min_version>XXX</min_version>
         <max_version>XXX</max_version>
         <appID>XXX</appID>
       </application>
     </compatible_applications>
   </version_range>
 </version_ranges>
</addon_compatibility>


I added a "type" attribute on <version_range> so that it could support whitelisting if/when we decide we need it in the future.

Comment 7

[Jeff Balogh (:jbalogh)]

unfocused: currently the API XML starts with

<?xml version="1.0" encoding="utf-8" ?>                                                   
<searchresults total_results="{{ total }}">  

where {{ total }} is the number of <addon> entries. Does firefox care about that number? Should it change to the total number of <addon> plus <addon_compatibility> entries?

Comment 8

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Jeff Balogh (:jbalogh) from comment #7)
> where {{ total }} is the number of <addon> entries

It's actually the total number of matching addons found, regardless of how many of those are included in the XML. For GUID search, the numbers are always the same. For normal search, the XML often won't include every matching addon, just the top X matching addons.

AFAIK, the client code ignores that attribute for GUID search. The only time it  cares about total_results is normal (text-based) search - to say "here's 20 results, but click here to view all 9000". So it probably makes sense to keep it as a count of all matching hosted addons. Which means for GUID search, it would be the number of <addon> elements in the XML.

Comment 9

[Jeff Balogh (:jbalogh)]

Merged in https://github.com/jbalogh/zamboni/commit/89b8873.

Comment 10

[Jeff Balogh (:jbalogh)]

Unfocused: I added an override for Adblock Plus at https://addons-dev.allizom.org/en-US/firefox/api/1.5/search/guid:%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D.

Oops, I forgot the type="incompatible" part.

Comment 11

[Jeff Balogh (:jbalogh)]

(In reply to Jeff Balogh (:jbalogh) from comment #10)
> Oops, I forgot the type="incompatible" part.

https://github.com/jbalogh/zamboni/commit/7ae2bbc

Comment 12

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Looks good :) Will work on the Addons Manager code for that next week (bug 693906).