Closed Bug 778326 Opened 12 years ago Closed 12 years ago

Create Permission.txt that explains permisson-names and purpose

Categories

(Core :: DOM: Device Interfaces, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla18
blocking-basecamp +

People

(Reporter: gwagner, Assigned: gwagner)

References

Details

(Whiteboard: [LOE:S], [qa-])

Attachments

(1 file, 3 obsolete files)

No description provided.
Summary: Create Permission.txt that → Create Permission.txt that explains permisson-names and purpose
Attached patch v1 (obsolete) (deleted) — Splinter Review
Before I go through all APIs I want some feedback how this should look like. Maybe like: Permission Name / API name 1) Short description 2) Possible types contacts / Contacts API 1) Add/Read/Modify the device contacts address book and read contacts from SIM card. 2) contacts {read, write, create} The types come from the discussion about the new format of .webapp files. For example: "permissions": { "mozbrowser": { description: "...", access: "read" }, },
Attachment #647366 - Flags: feedback?(jones.chris.g)
Comment on attachment 647366 [details] [diff] [review] v1 This is pretty epic bikeshedding, but how about alarm{read, write, create} // NB: is it "alarm-read" or "alarmread"? Alarm API Schedule a notification, or for an application to be started, at a specific time. contacts{read, write, create, delete} Contacts API Add/Read/Modify the device contacts address book and read contacts from SIM card.
Attachment #647366 - Flags: feedback?(jones.chris.g) → feedback+
FWIW, I think using an explicit "access" field is better than rolling the type of access into the permission name itself.
(In reply to Gregor Wagner [:gwagner] from comment #1) > The types come from the discussion about the new format of .webapp files. > For example: > "permissions": { > "mozbrowser": { > description: "...", > access: "read" > }, > }, I'm not sure on which ML this was discussed, but I think the description should not be bundled with the permission itself, since it is localizable but we don't want localizers to change the permission set itself. So maybe something like: permissions: { mozbrowser: "read", contacts: "read,write" } permissions_usage: { mozbrowser: "To browse the web", contacts: "To read and write your contacts" } fr_FR: { permissions_usage: { mozbrowser: "Pour naviguer sur le grand internet", contacts: "Pour lire et écrire dans votre carnet d'adresses" } }
Good point, Fabrice! I would like us to stay consistent with the existing mechanism for localization in the manifest, however. It's okay to include the description with the permission itself, as long as it is clear what the default_locale is. (For example: http://mozilla.github.com/webapps-spec/#example). This translates to a manifest that looks something like: { ... name: "MozillaBall", description": "Exciting Open Web development action!", permissions: { "mozbrowser": { description: "To browse the web" }, "contacts": { description: "To read and write your contacts", access: "read,write" } }, locales: { fr_FR: { name: "MozillaBalle", description: "Passionnant d'action de développement Open Web!", permissions: { mozbrowser: "Pour naviguer sur le grand internet", contacts: "Pour lire et écrire dans votre carnet d'adresses" } } }, default_locale: en, ... } Does this look reasonable?
(In reply to Anant Narayanan [:anant] from comment #5) > > Does this look reasonable? I'm not a big fan of having the default locale and other locales use a different property ("description" vs nothing) but I can live with that.
Assignee: nobody → anygregor
(In reply to Fabrice Desré [:fabrice] from comment #6) > I'm not a big fan of having the default locale and other locales use a > different property ("description" vs nothing) but I can live with that. Oh, sorry that was a mistake on my part; according to the spec, the properties under a locale must match the top-level hierarchy, so that section should actually read as: fr_FR: { permissions: { mozbrowser: { description: "Pour naviguer sur le grand internet" } } }
Ok, that looks perfect to me!
(In reply to Anant Narayanan [:anant] from comment #7) > (In reply to Fabrice Desré [:fabrice] from comment #6) > > I'm not a big fan of having the default locale and other locales use a > > different property ("description" vs nothing) but I can live with that. > > Oh, sorry that was a mistake on my part; according to the spec, the > properties under a locale must match the top-level hierarchy, so that > section should actually read as: > > fr_FR: { > permissions: { > mozbrowser: { > description: "Pour naviguer sur le grand internet" > } > } > } Right, that's how Jonas convinced me yesterday.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #2) > Comment on attachment 647366 [details] [diff] [review] > v1 > > This is pretty epic bikeshedding, but how about That's why I asked right when I started so bikeshedding doesn't matter at all. > > alarm{read, write, create} // NB: is it "alarm-read" or "alarmread"? > Alarm API > Schedule a notification, or for an application to be started, at a specific > time. > > contacts{read, write, create, delete} > Contacts API > Add/Read/Modify the device contacts address book and read contacts from SIM > card. Looks good to me!
Attached patch permissions (obsolete) (deleted) — Splinter Review
Attachment #647366 - Attachment is obsolete: true
Attached patch Permissions (obsolete) (deleted) — Splinter Review
First version.
Attachment #647653 - Attachment is obsolete: true
Attachment #648099 - Flags: review?(jones.chris.g)
Attachment #648099 - Flags: review?(jones.chris.g)
Attachment #648099 - Flags: feedback?(jonas)
Blocks: 772358
(In reply to Anant Narayanan [:anant] from comment #5) > ... > name: "MozillaBall", > description": "Exciting Open Web development action!", > permissions: { > "mozbrowser": { > description: "To browse the web" > }, > "contacts": { > description: "To read and write your contacts", > access: "read,write" > } > }, I am thinking that: access: "read,write" might be better as: access: {read: true, write: true} or for brevity: access: "rw"
There are only 4 different values that makes sense for the access field: * read * create * read+create * read+write+create So I don't think we'll want to have an array like ["read", "write"], or flags like { read: true, write: true }. Either of those options just lead to too much ability to set invalid combinations. So I'm suggesting that we just allow 4 different string values: access: "readonly" access: "createonly" access: "readcreate" access: "readwrite" Another nice thing with this is that "readonly" and "readwrite" matches what's used in a lot of other contexts (read-only memory, read-write web)
(In reply to Jonas Sicking (:sicking) from comment #14) > access: "readonly" > access: "createonly" > access: "readcreate" > access: "readwrite" > > Another nice thing with this is that "readonly" and "readwrite" matches > what's used in a lot of other contexts (read-only memory, read-write web) +1, since there are only 4 valid combinations, this makes the most sense.
blocking-basecamp: --- → ?
Why do you want to block on this?
Need this to codify the permission sets and syntax. Necessary for the permission model AFAIK (otherwise we should stop working on it for now).
Sure, agree with that, but this seems to be documentation, not a code bug.
The output is a document but the work is defining the exact permissions syntax and grammar. Seems like we need to figure that out in order to use permissions.
Ok, sounds good.
blocking-basecamp: ? → +
Attached patch patch (deleted) — Splinter Review
Attachment #648099 - Attachment is obsolete: true
Attachment #648099 - Flags: feedback?(jonas)
Attachment #658698 - Flags: review?(jonas)
Whiteboard: [LOE:S] → [LOE:S], [qa-]
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
http://mxr.mozilla.org/mozilla-central/source/extensions/cookie/Permission.txt#98 This says: 98 network-http 99 {} 100 old name: systemXHR But I can't find anything 'network-http' in the source, but I can find 'systemXHR'.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: