OK, I really wanted to gloss over this, but now Jeremy's going to make me elaborate :)

There are a few things I think we will eventually need to support worker development:

1) Some way to print out the values of things in a worker's global scope.
2) Similar debugging support for workers that we have for page script (breakpoints, etc).
3) When the user is selecting a worker for #1/#2, it might be useful to indicate what the parent(s) of the worker are to help developers select the right worker (in case there are nested workers). Or maybe it's not very useful - perhaps just having the URL of the worker base script is sufficient. We don't know yet.

None of these issues have anything to do specifically with SharedWorkers. Nor do I think that we should block development on arbitrary features like nested workers because we think we need better tools. A better solution would be to roll out a "just barely good enough" solution, get developer feedback on real use cases, and improve the tools over time to reflect that feedback, just as we do for every other feature in WebKit.

-atw


On Sat, Aug 1, 2009 at 1:06 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
I think logging to all connected pages' console is fine for now, but I think Michael's suggestion (or something similar) should be implemented in the not too distant future.  Definitely before shared workers are allowed to communicate with each other.

J


On Sat, Aug 1, 2009 at 12:45 PM, Michael Nordman <michaeln@google.com> wrote:
> it sounds like we have one vote for "just log them to the console for every connected document"

sgtm


On Sat, Aug 1, 2009 at 12:39 PM, Drew Wilson<atwilson@google.com> wrote:
> Yes, SharedWorkers will eventually be able to communicate with one another,
> as will DedicatedWorkers. So at some point we'll have a big connected graph
> of workers that potentially might be interesting for people to traverse and
> inspect their global contexts (I'm not sure - I don't think we know yet what
> debugging tools will be useful for developers).
> Further agreed, the HTML5 spec states that exceptions from shared workers
> are *not* propagated to parent pages for application execution - this would
> be solely for logging purposes.
> In the meantime while we work towards our glorious future, I'd still like to
> log exceptions somewhere :) It sounds like we have one vote for "just log
> them to the console for every connected document".
>
> -atw
>
> On Sat, Aug 1, 2009 at 10:35 AM, Michael Nordman <michaeln@google.com>
> wrote:
>>
>> Shared workers can also communicate directly with one another, is that
>> right? And its possible to have a shared worker whose only client is
>> another shared worker, is that right?
>>
>> Feels like we should be working towards inspecting shared workers
>> directly. Where a page inspector would show which shared workers it
>> was connected to, and you could open a separate inspector to see what
>> is going on within each shared worker (including which shared workers
>> it was connected to).
>>
>> Broadcasting exceptions within a worker to its clients for inspection
>> purposes may be useful even with separate inspectors per shared
>> worker. The client's 'shared worker' tab  (or console) could log
>> unhandled exceptions occurring in each, as you described, encouraging
>> the developer to look into it... open the shared worker inspector and
>> poke around.
>>
>> About broadcasting unhandled shared worker exceptions in general...
>>
>> It makes sense to have unhandled exceptions in a dedicated process
>> propagated to the parent page's context (which may presumably handle
>> the exception in some way). But I'm not sure that model applies to
>> unhandled exceptions in shared workers. The possibility of multiple
>> connected pages, which should "handle it"? Seems good for
>> logging/debugging purposes to have them show up in the client's
>> inspector, but doesn't sound like a good fit for application execution
>> purposes.
>>
>>
>> On Sat, Aug 1, 2009 at 9:31 AM, Drew Wilson<atwilson@google.com> wrote:
>> > Hi all,
>> > Currently, unhandled exceptions are sent from worker context over to the
>> > parent page where they are logged to the console. This works fine for
>> > dedicated workers, but not for shared workers which can have multiple
>> > active
>> > windows.
>> > The immediate solution that springs to mind is to broadcast the
>> > exception to
>> > every window associated with a shared worker, and have each window log
>> > the
>> > unhandled exception to its console. Is there another option that might
>> > be
>> > better (is there the concept of an inspector/console that is not
>> > associated
>> > with a specific window, for example)?
>> > -atw
>> > _______________________________________________
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> >
>
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev