Thanks everyone for the feedback. I've made the following changes to the design doc:
* Removed the ability to match every URL with @match * * Made it possible to match intranet hosts and IP addresses * Removed the .tld feature because there is no guarantee that google.<some public suffix> is "the same" as google.com. Moved this to a TODO. * Changed the ID to a fingerprint instead of a human-readable ID. Detailed responses below... On Wed, Dec 10, 2008 at 12:09 PM, [email protected] <[email protected]> wrote: > > Ojan brought this up before, but I think it's a good idea, so I'll > evangelize it some more. Instead of requiring the extension developer > to come up with an extension ID (com.google.myextension), use > templating to automatically substitute a guaranteed unique ID where > needed. The template substitution would be done in the browser > process before we handed the script off to a renderer. Examples: > - img.src = "${EXTENSION_URL}/foo.gif"; > - var extension = new chromium.Extension("${EXTENSION_ID}"); On Wed, Dec 10, 2008 at 3:53 PM, Erik Kay <[email protected]> wrote: > Unfortunately, I also think we couldn't do templating even if we > wanted to. What if you want to have multiple extensions that > cooperate with each other? They need a way to refer to each other. The templating is a good idea, but I agree with Erik that it would be a nice for extensions and content to be able to refer to extensions. On Wed, Dec 10, 2008 at 3:57 PM, Evan Martin <[email protected]> wrote: > I imagine for blacklisting we'll use what people typically use when > referring to a public key -- its fingerprint. > Those are about as long (in terms of filename characters) as a > com.google.foo namespace, and it keeps us down to one GUID (the public > key) rather than two (pubkey and java-style namespace). On Wed, Dec 10, 2008 at 4:19 PM, Ben Goodger (Google) <[email protected]> wrote: > Just as some additional data, we used GUIDs for ids in Firefox > initially, since they were uniquer, but they proved to be a pain on > the file system, where it was hard to tell one directory with a > gobbledegoop name from another. So we added support for contract id > names which allowed the provider more flexibility > (com.foo.bar/myextension). This made life for developers a little > easier. I never heard of conflicts becoming an issue. On Wed, Dec 10, 2008 at 4:19 PM, Ben Goodger (Google) <[email protected]> wrote: > Just as some additional data, we used GUIDs for ids in Firefox > initially, since they were uniquer, but they proved to be a pain on > the file system, where it was hard to tell one directory with a > gobbledegoop name from another. So we added support for contract id > names which allowed the provider more flexibility > (com.foo.bar/myextension). This made life for developers a little > easier. I never heard of conflicts becoming an issue. Using a fingerprint is a really cool idea. This would allow us to have a single authoritative ID but still have a short way to refer to it from other code. It also has the nice property that with signing it is impossible for two extensions created by different people to have the same key. I still worry about the developer overhead of having to deal with a random-looking GUID. For example using the fingerprint for the ID would mean that in order to set up a basic extension, you'd have to go generate a key pair on our developer website, since there is no way you could just create one by yourself. Also, in order to set up a user script that talked to the extension, you'd have to copy/paste your fingerprint from somewhere else since there's no way you could remember it. Finally, we'd have to generate uniqe names for directories based on the "Name" property in the manifest, since we wanted them to be human readable. I think these problems are tractable, though. We can create a really easy to use website that will generate you key pairs and the corresponding IDs. For the directories, we can do the extra legwork to make them human-readable. I think it's worth trying this idea out and seeing where the pain points are with the public key/fingerprint. We can always go back to a human-readable ID before launch if we decide it is too much hassle. On Wed, Dec 10, 2008 at 2:24 PM, Peter Kasting <[email protected]> wrote: > Nitpick: Your grammar for host/path seems a little wrong. I think you need > a mandatory "/" as the first character of the path. (Without this, I think > "http://www.google.foo";, which you claim is invalid, is actually OK.) Dunno > if you care that the current grammar allows illegal hosts/paths too. You are right. I took another swing at the grammar based on your other feedback. > As to matching hosts without registry-controlled domains: You should make > sure an author can code a script for an intranet site, e.g. "http://foo/";. > Probably also numeric addresses ("http://192.168.0.1/";, I don't care so > much about "http://123456789/";). You are right, that was a problem with the previous grammar. I have updated it so that IP addresses and intranet hosts are also supported. > For file:// support, why not allow "file" as a supported scheme, but not > include it in the "*" list? Authors who wish to support it can explicitly > add a match for it. I decided to just not have * be a valid value for the @match attribute. You can do http://*, https://*, file://*, etc. > I still think it would be nice to default to inject early, and inject at > content loaded later (if we ever do some sort of "greasemonkey compat mode" > we can flip the default for greasemonkey scripts). I say this because it > presents the user a more seamless experience, but I'm clueless about > actually writing these scripts, so perhaps this poses authors nasty > challenges. I want it to be easy to "upgrade" Greasemonkey scripts to extensions. Changing the injection point would work against this. I don't think the default injection point will prevent too many people from realizing they can inject earlier if they want to. - a --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
