On Thu, Aug 16, 2012 at 9:40 PM, Wil Clouser <[email protected]> wrote: > 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.
Ok, based on this thread, the latest UX flows for app updates and various in-hall discussions, I think we need the following metadata: * Version number * Hash of the package * Release notes (aka "what's new in this version"). This also needs to be localized. * Size of the download. This could in the future depend on which version of the app you currently have installed. There are a few ways we can provide this information. 1. Have the metadata available in a separate JSON file and add a property which links to package. 2. Have the metadata available in a separate JSON file and add a property in the webapp manifest in the app package which links to the metadata JSON. 3. Have the metadata available in a separate JSON file. Make the installPackage function take two URLs, one to the metadata JSON, and one to the app package. 4. Make the metadata available through headers when making a GET or HEAD request to the package. 5. Have the metadata available in a separate JSON file, and use headers to link to that when making a GET or HEAD request to the package. I think that the best solution of the above is 1. I.e. have a JSON file which contains all the needed metadata as well as the URL of the actual app package. The JSON file could follow the format of the webapp manifest as much as possible, though that's likely limited to mostly the localization parts. This would also be used during installation. When installPackage is called, we provide the URL just to the metadata JSON file. This file is downloaded and then we use the information there to download and install the app itself. Another nice thing about this approach is that for hosted apps, we can stick all this metadata in the webapp manifest. I.e. we'd simply merge the properties in the two JSON files. (This is something that packaged apps would automatically be allowed to do too. They could put a JSON file which contains both the webapp manifest and the update metadata both inside the package itself, and at the URL which is used for update checking. This is obviously not something they would have to do, but it would work if they so desired). What do you think? / Jonas _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
