Right, but the rating average doesn't take that into account.
Avi
On Fri, Dec 11, 2009 at 12:59 PM, Dirk Pranke wrote:
> If I'm running on Windows, I know to ignore the latter. That's a
> pretty big difference.
>
> -- Dirk
>
> On Fri, Dec 11, 2009 at 7:39 AM, Avi Drissman wrote:
> > What the d
If I'm running on Windows, I know to ignore the latter. That's a
pretty big difference.
-- Dirk
On Fri, Dec 11, 2009 at 7:39 AM, Avi Drissman wrote:
> What the difference between:
>
> ★ this extension doesn't work at all wh
>
> and
>
> ★ As mentioned, this extension is incomp
True...
It was noted earlier by James Robinson that a "properly written extension"
could detect and sniff the OS, and ensure that the correct binary was
loaded. But I never like pushing common work to the authors. If properly
handling "alternative platforms" (i.e. not Windows) involves work, guess
On Fri, Dec 11, 2009 at 10:39 AM, Avi Drissman wrote:
> What the difference between:
>
> ★ this extension doesn't work at all wh
>
> and
>
> ★ As mentioned, this extension is incompatible with my Linux box. Bad
> show. Bad show.
Presumably there will be far fewer people that i
What the difference between:
★ this extension doesn't work at all wh
and
★ As mentioned, this extension is incompatible with my Linux box. Bad
show. Bad show.
Avi
On Fri, Dec 11, 2009 at 10:29 AM, Mike Pinkerton wrote:
> One viewpoint I haven't seen mentioned on this threa
One viewpoint I haven't seen mentioned on this thread is from that of
the extension developer. Suppose they write, from their perspective, a
perfectly good extension that uses binary components. After being
around for a few weeks, they notice they have a 2-star rating and a
lot of angry comments sa
I believe the most elegant and quick (seemingly) solution is to provide the
extension developers a field (in the extension gallery, not in the extension
itself) that will include the platform and the version.
Going farther, you can add a check if the platform and the version (or even
let the develo
Yes, extensions that include NPAPI are a very small minority. Last
time I checked there were something like 5. It is a way out for people
who already have binary code that they would like to reuse, or who
need to talk to the platform.
I don't see what the big deal is about a few extensions only
su
The goal is to expose all this through Pepper.
On Thu, Dec 10, 2009 at 5:50 PM, Jeremy Orlow wrote:
> Much of what can't be done on the web platform also can't be done inside
> the NaCl sandbox.
>
>
> On Thu, Dec 10, 2009 at 5:49 PM, John Abd-El-Malek > wrote:
>
>> NaCl is the answer to all the
NaCl is the answer to all these problems...
On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow wrote:
> Or reject extensions that could be written without a NPAPI component.
> *ducks*
>
> On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting wrote:
>
>> On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman wrote:
Much of what can't be done on the web platform also can't be done inside the
NaCl sandbox.
On Thu, Dec 10, 2009 at 5:49 PM, John Abd-El-Malek
wrote:
> NaCl is the answer to all these problems...
>
> On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow wrote:
>
>> Or reject extensions that could be writ
Or reject extensions that could be written without a NPAPI component.
*ducks*
On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting wrote:
> On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman wrote:
>
>> Q: Can't we have the extensions gallery warn that it won't work?
>> A: Sorry, we can't do that in an a
We do? I didn't know that. Then we should enforce some kind of labeling.
Avi
On Thu, Dec 10, 2009 at 8:12 PM, Peter Kasting wrote:
> On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman wrote:
>
>> Q: Can't we have the extensions gallery warn that it won't work?
>> A: Sorry, we can't do that in an au
On Thu, Dec 10, 2009 at 5:05 PM, Avi Drissman wrote:
> On Thu, Dec 10, 2009 at 8:00 PM, Ojan Vafai wrote:
>
>> I think we can wait to see what percentage of extensions actually include
>> binaries before devoting too much time to this. Our expectation is that this
>> will be a very small percent
On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman wrote:
> Q: Can't we have the extensions gallery warn that it won't work?
> A: Sorry, we can't do that in an automated fashion. The extensions author
> should mention it. Too bad they don't.
>
But we explicitly review patches with binary components.
On Thu, Dec 10, 2009 at 8:00 PM, Ojan Vafai wrote:
> I think we can wait to see what percentage of extensions actually include
> binaries before devoting too much time to this. Our expectation is that this
> will be a very small percentage, right?
>
If we give people the capabilities, people wil
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman wrote:
> Andy sent me a CL for review about an extension crashing (
> http://crbug.com/29584). Turns out the cause was a failure to load a
> Windows .dll on the Mac.
>
> Huh? Then I went to look at the docs (
> http://code.google.com/chrome/extensions
On Thu, Dec 10, 2009 at 7:55 PM, Ojan Vafai wrote:
> I think we can wait to see what percentage of extensions actually include
> binaries before devoting too much time to this. Our expectation is that this
> will be a very small percentage, right?
>
Quick, look at
https://chrome.google.com/exten
On Thu, Dec 10, 2009 at 4:38 PM, Avi Drissman wrote:
> On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin wrote:
>
>> Distributing binaries on Linux = sadness, as the Flash guys will tell
>> you.
>> [...]
>>
>> In summary, all I offer you is more problems and the plea that we
>> should really really
On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin wrote:
> Distributing binaries on Linux = sadness, as the Flash guys will tell
> you.
> [...]
> In summary, all I offer you is more problems and the plea that we
> should really really deter people from doing this kind of thing. I
> imagine a dystopia
Is there a timetable? http://crbug.com/14936 has been Mstone-Xed since June.
Avi
On Thu, Dec 10, 2009 at 7:30 PM, Aaron Boodman wrote:
> On Thu, Dec 10, 2009 at 4:27 PM, Avi Drissman wrote:
> > Can we have the syntax say "platform x loads x.dll, platform y loads
> y.so,
> > etc"?
>
> Yes that
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman wrote:
> If we had something like:
>
> "plugins": {
> "mac": ...
> "win": ...
> "linux": ...
> }
FWIW, one reason to avoid this sort of thing is that there is really
no single thing called "linux" to target. For example, because our
builds of C
It is good that we can avoid the crash. We do need to get some kind of
syntax in the manifest.
- a
On Thu, Dec 10, 2009 at 4:18 PM, Avi Drissman wrote:
> The crash is fixed. But the fact that we're now expecting random dll loads
> to fail prevents us from giving good UI to users, and not labelli
On Thu, Dec 10, 2009 at 4:27 PM, Avi Drissman wrote:
> Can we have the syntax say "platform x loads x.dll, platform y loads y.so,
> etc"?
Yes that is the idea.
> If a dll required by a platform fails to load, we need to alert the user
> that their extension is busted. The prospect of having fail
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman wrote:
> Andy sent me a CL for review about an extension crashing
> (http://crbug.com/29584). Turns out the cause was a failure to load a
> Windows .dll on the Mac.
We have had threads on this before. The consensus was that it was
possible to simply f
Can we have the syntax say "platform x loads x.dll, platform y loads y.so,
etc"?
If a dll required by a platform fails to load, we need to alert the user
that their extension is busted. The prospect of having failure to load
binaries be an expected thing scares me.
Avi
On Thu, Dec 10, 2009 at 7:
The crash is fixed. But the fact that we're now expecting random dll loads
to fail prevents us from giving good UI to users, and not labelling what
platforms it'll work on prevents us from warning in advance.
Imagine a million angry Mac and Linux users filing bugs because their
favorite extension
Can we at least deny installing the extension in Chromium if it contains
plugins that cannot be used in that operating system for now until a better
design for cross-platform manifest?
- Mohamed Mansour
On Thu, Dec 10, 2009 at 7:15 PM, Matt Perry wrote:
> Yeah, that's very bad. I knew the NPAP
That's http://code.google.com/p/chromium/issues/detail?id=14936 . The
was an internal thread ("Binary files an a crx") a while ago on this.
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman wrote:
> Andy sent me a CL for review about an extension crashing
> (http://crbug.com/29584). Turns out the cau
Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on it
because we didn't like any of the alternatives. (Even if we do have a
manifest syntax for it, the extension package becomes bloated with plugin
binaries for other platforms.) But I didn't realize that it could cause a
crash.
http://codereview.chromium.org/492012
So the design is for every platform to try to load all plugins. We don't
even want to have a hint that allows the website to say "this is
Windows-only"?
How about from the browser perspective? Is failure to load a library a fatal
error? ("Sorry, we can't load
Andy sent me a CL for review about an extension crashing (
http://crbug.com/29584). Turns out the cause was a failure to load a Windows
.dll on the Mac.
Huh? Then I went to look at the docs (
http://code.google.com/chrome/extensions/npapi.html):
{
"name": "My extension",
...
*"plugins": [
32 matches
Mail list logo