Thanks. Please see my comments inline. On Oct 29, 2:32 pm, "Linus Upson" <[EMAIL PROTECTED]> wrote: > First thoughts: > > 1. It would be good if this proposal converged in some way with HTML 5 workers
We're trying to converge with web worker as defined in HTML 5. > > 2. There needs to be a way to name and communicate with these tasks > (perhaps HTML 5 worksers have such a thing?) Yes, cross-process communication is supported via MessagePort as defined in HTML 5 web worker spec. > > 3. I also don't see a need for the "start onbrowserlaunch" option Removed. > > 4. I don't think we should make any process/thread guarantees in the > API. That should be an implementation detail Removed. > > 5. Please get feedback from Aaron Boodman and Chris Prince who have > done extensive work on ... uh... workers. We're going to talk with Aaron and Chris to see how background task can be merged with the web worker. > > Linus > > On Wed, Oct 29, 2008 at 2:03 PM, Nick Baum <[EMAIL PROTECTED]> wrote: > > Permissions: I agree with Brian that drag-n-drop is somewhat clumsy for > > granting permissions (see how well that works for bookmarklets...). I'm > > syncing up with Mike Smith on this tomorrow, and Glen and I will work on a > > better > > solution. > > > Also, what happens next time I visit the app? Is it authorized to launch the > >backgroundtask, or do I have to re-authorize it? > > > Lifetime: Do we need the "start onbrowserlaunch" option? What's the use > > case for this? > > > Process model: Are there cases when abackgroundtaskwould need to > > communicate with the tab that created it? For example, opening an event in > > an existing calendar window. > > > Overall, this seems like a well thought-out proposal! > > > -Nick > > > On Wed, Oct 29, 2008 at 1:11 PM, Dmitry Titov <[EMAIL PROTECTED]> wrote: > > >> Good idea about OK delay... > >> That part of the proposal is indeed the most controversial. Some folks > >> love it, some hate it. Modal dialog can provide UI for "learn more...", ask > >> for specific permissions, perhaps even capture credentials to use while > >> running in thebackground. On the other side, "Allow/Deny" dialogs are > >> sometimes bad because they basically shift blame to the user w/o > >> transparency on what's going on. > >> So we do expect opt-in mechanism will perhaps change - please voice any > >> idea you like more. > >> Dmitry > >> On Tue, Oct 28, 2008 at 6:43 PM, Brian Rakowski <[EMAIL PROTECTED]> > >> wrote: > > >>> Drag and drop seems like a clumsy and unfamiliar mechanism for granting > >>> this capability. A modal dialog would be better. We can inject a delay on > >>> making the OK button active if we are worried about clever attacks that > >>> get > >>> users to click on an OK that appears underneath the cursor. > >>> -Brian > > >>> On Tue, Oct 28, 2008 at 5:55 PM, [EMAIL PROTECTED] > >>> <[EMAIL PROTECTED]> wrote: > > >>>> Hi all, > > >>>> Here is a draft of a design doc forBackgroundBrowserTask: > > >>>>http://docs.google.com/View?docid=dd6rm2wb_3fmz8pnnp > > >>>> Your feedback is appreciated. > > >>>> Thanks, > > >>>> Jian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
