Utility process is an amenable idea. We do something like that for first-run import as well.
Key items, I can think of: 1- Utility process would not display UI (would it?) 2- We can allow a directory to be available for read/write 3- Use IPC for progress / heartbeat In other words pretty much a custom renderer. For the images I am lost. Unless we transcode I don't see the point. Transcoding to a format that we handle well or that is not crazy would mitigate most attacks. Or mandate the image format and do a cursory decoding to validate. On May 1, 11:17 am, Aaron Boodman <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
