Thanks for the replies! On Fri, May 1, 2009 at 10:42 AM, Adam Barth <[email protected]> wrote: > I think we should go with the utility process. We've seen several > examples where this would be a useful concept to have.
On Fri, May 1, 2009 at 10:48 AM, Erik Kay <[email protected]> wrote: > There have been other cases people have brought up where the work being > requested wasn't associated with a renderer (PAC parsing for example). With > the extension example, I think it could be associated with a renderer, but > in some cases, we'd be opening up a new one (say you double click on a crx On Fri, May 1, 2009 at 10:48 AM, Ojan Vafai <[email protected]> wrote: > An advantage of the utility process is that it's not tied to the lifetime of > the tab, so we don't have to deal with edge cases like when the user closes > a tab that's mid-installing an extension. I hadn't thought of the double-click the CRX case. If this is the only example, I'd be willing to lose this feature, to be honest. I think losing an in-process install when the tab that started it goes away would be reasonable behavior. On the other other hand, implementing a utility process doesn't seem like a huge amount of work, and I guess it would be useful for other chromium systems. I guess the bigger issues is getting data in and out of whichever process we do the work in. On Fri, May 1, 2009 at 10:42 AM, Adam Barth <[email protected]> wrote: > As for the zip libraries, I seem to recall that we can marshal file > handles into sandboxed processes, but I'm not an expert on this. On Fri, May 1, 2009 at 10:48 AM, Erik Kay <[email protected]> wrote: > I think the max was actually 10M. Perhaps we'd need to implement it as a > streaming API. Isn't that kind of logic already in place for audio/video? > > Perhaps the renderer could just have read access to the zip file, and then > pass the files it's unpacking one-by-one up to the browser. If the zip has > any single large files, that gets expensive though. On Fri, May 1, 2009 at 10:45 AM, Nicolas Sylvain <[email protected]> wrote: > We've talked about this for a bunch of different reasons, and always > pushed back. But maybe the gears team was going to do that anyway? I'm > not sure what we decided at the end. > Either way, can you modify your zip library to take a file handle instead of > a filename? > If so, we have everything you need to pass a file handle across processes, > or > even better, a memory map file. We can use DuplicateHandle() to get the input file handle in, but I am not sure what to do about getting the directory sturcture out. I thought perhaps the case with Gears was slightly different, but I'm not sure why. Here, all we would need is a temporary directory (any temporary directory) we could use to do work in. In Gears, we needed access to a particular path. On Fri, May 1, 2009 at 10:48 AM, Erik Kay <[email protected]> wrote: > For normal extensions where images are always just rendered in HTML, we > don't need to do anything special with the images. They'll always be read > and rendered in the renderer. The issue with needing to decode images in the package is going to come up for other things. Finnur brought up one example, PageActions. But I forsee us needing to display images that came with the extension in the browser for other reasons. > The issue with images is with themes, since they're displayed by the browser > process. I'm not sure I followed your flow with this. At install time, you > ship decoded images over to the browser process so it can display them. > Does it need to re-encode the images itself for storage to disk? Or is it > going to need to ask the renderer to decode each time? I was thinking that ideally, the renderer would just "unpack" the extension into whatever directory structure is useful to us. It could be that part of this would be decode any images into bitmaps that we store along side the extension. Later on, the browser process refers to these. - a --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
