My main problem with that is that it's a horrible end-user experience --- "All I want is this extension, and I don't know which of these plethora of choices to pick". My preference, both as a user and a developer of extensions, would be to make it easy to package everything up so as to provide a single extension to the public.
Regards, Simon On Fri, Sep 11, 2009 at 7:52 PM, Mohamed Mansour <[email protected]> wrote: > Why not just let the extension developer do different versions him/herself. > When I download an extension, I don't want to download libraries/plugins > from 10 different architectures. If my operating system is Windows, I would > want to download just the .dll file. The extension developer could release > different versions: > hello_world_win32.crx > hello_world_linux32.crx > Choose whatever filename they please. Maybe include what John stated, a > manifest to tell it what the extension supportedPlatform is, so we would > know at install time that the extension is no supported. > - Mohamed Mansour > > > On Thu, Sep 10, 2009 at 2:36 PM, jat <[email protected]> wrote: >> >> I am building a GWT plugin for Chrome, and I think the manifest should >> definitely include some indication of which platform a particular >> binary is intended for. Trying to load them all and letting them fail >> seems dangerous, as the differences between some platforms may not be >> sufficient to prevent the library from loading (say two ELF-based x86 >> Unix distros). >> >> I think Chrome should come up with a set of platform identifiers that >> correspond to what are different builds, and the plugins should be >> able to be associated with a particular platform. For backwards >> compatibility, we could try and load any plugin without a platform tag >> and hope it will fail to load if it isn't compatible, but that should >> be deprecated. I think the proposal at the beginning of this thread >> is fine, or you could simply add a new tag on the plugins entry, like >> this: >> ... >> "plugins": [ >> { "path": "WINNT_x86-msvc/foo.dll", "public": true, "platform": >> "WINNT_x86-msvc" }, >> { "path": "Linux_x86_64-gcc3/libfoo.so", "public": true, >> "platform": "Linux_x86-gcc3" }, >> { "path": "Linux_x86_g4-gcc3/libfoo.so", "public": true, >> "platform": "Linux_x86_64-gcc3" } >> ], >> ... >> (path could still be anyway the developer wanted to organize the >> libraries). Using a fixed naming convention would work, but it seems >> awkward and doesn't save much over just specifying the platform >> explicitly. >> >> Also, we need a way to know at install time that the extension is not >> supported on the current platform. Since conceivably the extension >> might have an optional plugin and still operate without it on some >> platforms, I think that means adding a new manifest entry like >> supportedPlatforms: [ platforms ], and when you try and install the >> CRX it will tell you the extension is not supported on your platform >> if that tag is present but does not contain the current platform. >> >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
