{"action":"created","issue":{"url":"https://api.github.com/repos/heycam/webidl/issues/552","repository_url":"https://api.github.com/repos/heycam/webidl","labels_url":"https://api.github.com/repos/heycam/webidl/issues/552/labels{/name}","comments_url":"https://api.github.com/repos/heycam/webidl/issues/552/comments","events_url":"https://api.github.com/repos/heycam/webidl/issues/552/events","html_url":"https://github.com/heycam/webidl/issues/552","id":318512966,"number":552,"title":"Introduce new string type for names/keys with length limit","user":{"login":"inexorabletash","id":771547,"avatar_url":"https://avatars0.githubusercontent.com/u/771547?v=4","gravatar_id":"","url":"https://api.github.com/users/inexorabletash","html_url":"https://github.com/inexorabletash","followers_url":"https://api.github.com/users/inexorabletash/followers","following_url":"https://api.github.com/users/inexorabletash/following{/other_user}","gists_url":"https://api.github.com/users/inexorabletash/gists{/gist_id}","starred_url":"https://api.github.com/users/inexorabletash/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/inexorabletash/subscriptions","organizations_url":"https://api.github.com/users/inexorabletash/orgs","repos_url":"https://api.github.com/users/inexorabletash/repos","events_url":"https://api.github.com/users/inexorabletash/events{/privacy}","received_events_url":"https://api.github.com/users/inexorabletash/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2018-04-27T18:52:03Z","updated_at":"2018-04-30T16:13:20Z","closed_at":null,"author_association":"NONE","body":"Many places in the platform allow DOMStrings for map keys or resource names, e.g. localStorage keys, Indexed DB database/store/index names, Service Worker Cache names, and so on. Specs do not define length limits, making it up to the UA to impose a limit to prevent OOMs. Rather than forcing each spec to specify a limit and behavior, we could introduce a new string type in WebIDL so that specs just need to use the type and bindings code in each UA will do the work.\r\n\r\nContext:\r\n* https://github.com/w3c/ServiceWorker/issues/1310 (SW's Cache API)\r\n* https://github.com/inexorabletash/web-locks/issues/36 (proposal for a Locks API)\r\n* https://github.com/w3c/IndexedDB/issues/207 (IDB discussion about problems with arbitrary length strings; we didn't do anything specific there)\r\n\r\nPlausible names include \"KeyString\" or \"NameString\", but I'm not a huge fan of either. \"Key\" only makes sense if the map is fairly explicit. \"Name\" could imply that these are human readable and thus should be normalized, have locale-aware collation, etc.\r\n\r\nSince I'm a nerd I have a hard time not picking a power-of-two limit (e.g. 1024), or feeling like I'm intentionally avoiding picking such a number (e.g. 1000).\r\n\r\nBut as a straw man:\r\n\r\n> **NameString**\r\n> The NameString type corresponds to the set of all possible sequences of code units up to length 1000. Such sequences are commonly interpreted as UTF-16 encoded strings although this is not required. \r\n>\r\n>> Specifications should use the NameString type to represent strings that are provided by script to serve as the programmatic names of resources, such as the names of database tables or keys in a configuration map. These strings are assumed to have a fixed length within a web application, and to not contain arbitrary user data.\r\n\r\nAnd the ECMAScript binding steps would be something like:\r\n\r\n> An ECMAScript value V is converted to an IDL NameString value by running the following algorithm:\r\n> 1. Let x be ToString(V).\r\n> 1. If the length of x is greater than 1000, then throw a TypeError.\r\n> 1. Return the IDL NameString value that represents the same sequence of code units as the one the ECMAScript String value x represents.\r\n> \r\n> The result of converting an IDL NameString value to an ECMAScript value is the String value that represents the same sequence of code units that the IDL NameString represents.\r\n\r\nSee also: \r\n* #335 - i.e. we'd probably want something over in [Infra](https://infra.spec.whatwg.org/) too\r\n"},"comment":{"url":"https://api.github.com/repos/heycam/webidl/issues/comments/385448082","html_url":"https://github.com/heycam/webidl/issues/552#issuecomment-385448082","issue_url":"https://api.github.com/repos/heycam/webidl/issues/552","id":385448082,"user":{"login":"domenic","id":617481,"avatar_url":"https://avatars0.githubusercontent.com/u/617481?v=4","gravatar_id":"","url":"https://api.github.com/users/domenic","html_url":"https://github.com/domenic","followers_url":"https://api.github.com/users/domenic/followers","following_url":"https://api.github.com/users/domenic/following{/other_user}","gists_url":"https://api.github.com/users/domenic/gists{/gist_id}","starred_url":"https://api.github.com/users/domenic/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/domenic/subscriptions","organizations_url":"https://api.github.com/users/domenic/orgs","repos_url":"https://api.github.com/users/domenic/repos","events_url":"https://api.github.com/users/domenic/events{/privacy}","received_events_url":"https://api.github.com/users/domenic/received_events","type":"User","site_admin":false},"created_at":"2018-04-30T16:13:20Z","updated_at":"2018-04-30T16:13:20Z","author_association":"COLLABORATOR","body":"We could also use an extended attribute for this these days, now that they're attached to types. That would allow it to work with USVString or ByteString as well."}}
{"actor":{"display_login":"domenic"}}