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 <j...@google.com> 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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to