-
-
Save lloyd/817202 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The origin should be an ASCII URL, that is, non-ASCII characters | |
should be normalized down to ASCII. | |
LH: The UA should handle idna for us. I think this is a noop. | |
We are relying on urlmatch.js's normalization of :80 etc, not testing | |
that directly (because it makes the tests hard to run). We should | |
verify that all URLs are being normalized in all code paths. | |
LH: done: http://bit.ly/egj8zU | |
Widgets are allowed in the code but not noted in the spec, need to be | |
readded. Takes a path and a preferred size, like {"widget": {"path": | |
"/widget.html", "width": 100, "height": 100}}. Height and width are | |
optional and are suggestions (the dashboard may not respect the | |
suggestion). (List of preferred sizes?) | |
LH: done: http://bit.ly/hHvdmo | |
To actually construct a URL from a manifest you need the full | |
installation object, which contains the origin; the manifest itself | |
does not contain the origin. They "key" is the origin | |
LH: yay! | |
urlmatch.js allows for username:password@, but that doesn't have any | |
meaning or place in this specification. | |
LH: unsure what to do. we could explicitly disable it, throw an error... thoughts? | |
"capabilities" are mentioned, but with no meaning. Should we have | |
something in the spec that has no meaning? It presupposes that it | |
will have a meaning, but since we havne't determined a meaning that | |
seems premature and like it's sneaking in a feature without clear | |
discussion. | |
LH: yeah, I don't know what we should do about capabilities. it's a discussion | |
we should start on list, shouldn't block merge tho. | |
Icons are not clearly specified. Maybe we can take the specification | |
from <link rel="icon">? | |
LH: hmm | |
There's no maximum or preferred length on name and description. It's | |
not specified how it should be rendered; presumably all markup is | |
quoted (but e.g., <> is allowed) and whitespace is normalized (i.e., | |
newlines become spaces). | |
LH: name? 512? desc? 4k? | |
Should locales have a whitelist of things that are allowed to be | |
overridden? Now it's a rough blacklist. IMHO only human-readable | |
things should be replaceable (possibly including the icons, which are | |
readable in a sense). Origin was originally kind of allowed for, but | |
does not seem valid any more. (This means, e.g., you must install the | |
English Wikipedia or the Spanish Wikipedia, you can't select language | |
after installation -- but that represents a real institutional divide | |
in Wikipedia anyway.) | |
LH in code, it's actually a whitelist right now. search for may_overlay in manifest.js | |
version: Presumably it's not even sortable in any sense? Also, not | |
user visible? | |
LH: totally and completely opaque to the repository. an unfortunate implementation | |
detail to mitigate problems caused by manifest updates requiring prompting. this may | |
change depending on the fates of capabilities. | |
We should probably point out that origin includes http/https and port. | |
LH: I don't mind adding language, you don't think 'origin' is widely understood? | |
http://en.wikipedia.org/wiki/Same_origin_policy | |
I'm not sure what if anything Last-Modified on the manifest will | |
accomplish or do? Is that value stored in the installed record? Does | |
it provide a default for version if it is not otherwise specified? | |
LH: No. That sentence is a vestige. Do we even need to mention that | |
app devs may serve their files using standard headers in the appropriate way? | |
I don't think its necc. | |
We don't say how unknown keys are handled. I think they should be | |
ignored in all positions (e.g., manifest.developer.email should be | |
okay, just ignored). Also not just validation, but if they are | |
preserved when stored in the repo. This also implies that the | |
presence of any value cannot mean user confirmation, as a user agent | |
that didn't understand the key may have installed the app. | |
Confirmation should be stored separately, as a positive assertion. | |
The presence of any value (outside origin which we have encoded in | |
version 0, essentially) does not mean the user was fully notified and | |
consented to that value. | |
LH: I'm fine with allowing unknown keys. let's start a small discussion | |
on list? I can start it. | |
default_locale could be optional if the "locales" key is not in the manifest. In that case there's no localization possible anyway, so the "best" locale is always the "only" locale, be it "en" or "es" or whatever. | |
LH: I like this change too. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment