On 08/15/2012 04:20 PM, Andy McKay wrote: > On 15/08/2012, at 4:08 PM, Jonas Sicking wrote: >> So the question is. What metadata would we want to send which >> prohibits this solution? > > Can a user optionally choose to update? I might not want to update version > 1.2 because it breaks functionality. For this reason, the addon update > includes a link to the release notes for each version, if specified. > > The addon update also includes browser versions. I'm hoping that run time > versions is not something we'll get into, but in the future I can see an app > not working on certain run times because APIs are lacking. > >> What other solutions do people have in mind >> for updates?
As Andy wrote, the add-on update metadata includes versions, a file hash, and a link to a changelog. In addition to those, apps may be interested in permission changes (even if it's just a binary flag at first) and major/minor changes (we talked about upgrading a local database when a new version of the app comes out). Those are off the top of my head, there will likely be others. Parsing a blob of JSON leaves us a lot of flexibility, depending on GET and some combination of headers feels like a clean idea at first, but the lack of extensibility makes me nervous. Wil _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
