[webkit-dev] How to compile testbindings under WebCore/bridge?
Hi all, i'm looking for the methods to bridge C object into JS runtime, then i found the test cases under WebCore/bridge which seems to be a good sample for me, because i found similar codes in Qt port, so i want to try out "testbindings.cpp" to see whether the C bridge works. However, i cannot use "make_testbindings" script to compile the source code, can anybody kindly show some tips to play with it? Many thanks in advance for the helps! (Btw, i'm using the latest r44282 source package, not the svn trunk.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rendering Video using video overlay rather than on a Cairo surface (Graphics overlay)
On Sat, May 30, 2009 at 9:22 PM, Simon Fraser wrote: > > Something else you should consider here is ways that the video can be clipped > and transformed. Thanks Simon, I forgot that > > Any solution which naively puts a hardware surface over some rect where the > video is supposed to be will be broken in many cases. Thinking aloud; the only option seems to be is to convert the YUV output of the decoder to a RGB surface, which is mapped in to Cairo surface; this way Webkit is free to do those crazy CSS Transforms; YUV to RGB will kill the processor (unless done in HW) But for any embedded core running around 300~400MHz this will never work for even d...@25 fps (forget HD) Now. how can we accelerate this ? I assume clip will always translate to a paint / setSize function. So that can be handled in HW. Is that right ? Is there a way to decently accelerate all the video layer CSS transforms ? Is it possible to send the Transform down to RenderVideo and then to the MediaPlayer ? Some chips do provide HW transform functions; > > This is exactly what the ACCELERATED_COMPOSITING code path does. There is > currently a Core Animation backend for Mac (GraphicsLayerCA.mm); you'd have > to > write a backend for your compositing system if you wish to use this code > path. Does this handle the CSS transforms as well ? -- Sriram Neelakandan Author - Embedded Linux System Design And Development (http://tinyurl.com/2doosu) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Webkit capture web page content API
Can this be done using only Webkit API(without cocoa)? Am basically trying to capture the web page content on windows and would like to do it with Webkit. Darin Adler wrote: > > On May 13, 2009, at 8:59 AM, Lucius Fox wrote: > >> But if Webkit is not involved. That means it can not capture the web >> content which is not within the visible area (e.g. a page is long >> and it has scroll bar)? > > To capture more than what’s currently visible you can use these NSView > methods with the [[[webView mainFrame] frameView] documentView] view > rather than the web view itself. > > -- Darin > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -- View this message in context: http://www.nabble.com/Webkit-capture-web-page-content-API-tp23516755p23813818.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JSObjectMakeFunction question
Hi all, I'm attempting to use the function JSObjectMakeFunction described here: http://gemma.apple.com/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/JSObjectRef/index.html I would like to call a JavaScript function from C. I assume the following is required: 1. Create a function using JSObjectMakeFunction. 2. Add it as a property of the Window JSObjectRef. 3. Call it using JSObjectCallAsFunction. However JSObjectMakeFunction has the following signature: JSObjectRef JSObjectMakeFunction( JSContextRef ctx, JSStringRef name, unsigned parameterCount, const JSStringRef parameterNames[], JSStringRef body, JSStringRef sourceURL, int startingLineNumber, JSValueRef *exception); My question is about the parameters to this function: JSStringRef body - Since I wish to call a JavaScript function from C, why would I specify the body of the function. Surely this would be implemented by the JavaScript developer? I don't understand this parameter in the context of calling a user defined JavaScript function from within C. Can anyone help? Cheers, Jack ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSObjectMakeFunction question
2009/6/1 Jack Wootton : > Hi all, Hi! > I'm attempting to use the function JSObjectMakeFunction described here: > > http://gemma.apple.com/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/JSObjectRef/index.html > > I would like to call a JavaScript function from C. I assume the > following is required: > > 1. Create a function using JSObjectMakeFunction. > 2. Add it as a property of the Window JSObjectRef. > 3. Call it using JSObjectCallAsFunction. JSObjectMakeFunction creates a JavaScript function *from* C. To just call a JS function (not create one), all you need to do is get the function object (most likely JSObjectGetProperty() on the global object) and then call it with JSObjectCallAsFunction(). -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
22.05.2009, в 3:20, Drew Wilson написал(а): SharedWorkers have explicit access to the ApplicationCache APIs, while dedicated Workers merely inherit the ApplicationCache from their parent window. What is the use case for this? It doesn't seem useful to me - to invoke update explicitly, one normally needs to have UI anyway, at which point it's much easier to call update() directly from a page. A tangentially related question: what will happen to a SharedWorker whose cache got updated? Will the repository use a new source for new instances, while the old ones will continue to run? Looks like there is a significant potential for mistakes here, as scripts won't normally expect several instances of the same SharedWorker to be active. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSObjectMakeFunction question
It seems some casting is required for this though? JSValueRef JSObjectCallAsFunction( JSContextRef ctx, JSObjectRef object, JSObjectRef thisObject, size_t argumentCount, const JSValueRef arguments[], JSValueRef *exception); The above function accepts a JSObjectRef object. However JSValueRef JSObjectGetProperty( JSContextRef ctx, JSObjectRef object, JSStringRef propertyName, JSValueRef *exception); returns JSValueRef Looking at the typedefs in APICast.h typedef const struct OpaqueJSValue* JSValueRef; typedef struct OpaqueJSValue* JSObjectRef; If I didn't cast, then wouldn't I be attempting to pass a const value into a function that accepts a non-const parameter? It is however reporting a compilation error because the types don't' match, On Mon, Jun 1, 2009 at 2:53 PM, Kalle Vahlman wrote: > 2009/6/1 Jack Wootton : >> Hi all, > > Hi! > >> I'm attempting to use the function JSObjectMakeFunction described here: >> >> http://gemma.apple.com/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/JSObjectRef/index.html >> >> I would like to call a JavaScript function from C. I assume the >> following is required: >> >> 1. Create a function using JSObjectMakeFunction. >> 2. Add it as a property of the Window JSObjectRef. >> 3. Call it using JSObjectCallAsFunction. > > JSObjectMakeFunction creates a JavaScript function *from* C. > > To just call a JS function (not create one), all you need to do is get > the function object (most likely JSObjectGetProperty() on the global > object) and then call it with JSObjectCallAsFunction(). > > -- > Kalle Vahlman, z...@iki.fi > Powered by http://movial.com > Interesting stuff at http://sandbox.movial.com > See also http://syslog.movial.fi > -- Regards Jack ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSObjectMakeFunction question
On Jun 1, 2009, at 8:29 AM, Jack Wootton wrote: It seems some casting is required for this though? Yes, conversion to JSObjectRef is needed, although you don’t have to do any casting. You can call JSValueToObject to turn the value into an object, making the appropriate object wrapper for non-object types. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSObjectMakeFunction question
On Jun 1, 2009, at 8:29 AM, Jack Wootton wrote: It seems some casting is required for this though? JSValueRef JSObjectCallAsFunction( [snip] The above function accepts a JSObjectRef object. However JSValueRef JSObjectGetProperty( [snip] returns JSValueRef Setting aside the actual typedefs (which are our attempt to trick the C type system), JavaScript has objects and some primitive values that are not objects. So every object is a kind of value, but not all values are objects. JSObjectGetProperty retrieves a property from an object, and it can't guarantee whether the result will be an object or a primitive, so it returns JSValueRef. If you can be certain the value is in fact an object (functions are a kind of object), you can just downcast. If you are not certain (for example the property can be defined or altered by script), you can use JSValueIsObject to check before casting. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSObjectMakeFunction question
On Jun 1, 2009, at 8:55 AM, Darin Adler wrote: On Jun 1, 2009, at 8:29 AM, Jack Wootton wrote: It seems some casting is required for this though? Yes, conversion to JSObjectRef is needed, although you don’t have to do any casting. You can call JSValueToObject to turn the value into an object, making the appropriate object wrapper for non-object types. That's a possible alternative to my suggestion (in other email)l. In this particular case, it would be fruitless to attempt to call the object wrapper for a primitive value as a function, so it's may be better idea to do the check up front. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rendering Video using video overlay rather than on a Cairo surface (Graphics overlay)
On Jun 1, 2009, at 12:47 AM, Sriram Neelakandan wrote: On Sat, May 30, 2009 at 9:22 PM, Simon Fraser wrote: Something else you should consider here is ways that the video can be clipped and transformed. Thanks Simon, I forgot that Any solution which naively puts a hardware surface over some rect where the video is supposed to be will be broken in many cases. Thinking aloud; the only option seems to be is to convert the YUV output of the decoder to a RGB surface, which is mapped in to Cairo surface; this way Webkit is free to do those crazy CSS Transforms; YUV to RGB will kill the processor (unless done in HW) But for any embedded core running around 300~400MHz this will never work for even d...@25 fps (forget HD) Now. how can we accelerate this ? I assume clip will always translate to a paint / setSize function. So that can be handled in HW. Is that right ? Clipping in hardware is tricky. You have to consider that there may be CSS transforms between the video and its clipping container, so it's not as simple as just some rect of the video being exposed. Is there a way to decently accelerate all the video layer CSS transforms ? Is it possible to send the Transform down to RenderVideo and then to the MediaPlayer ? Some chips do provide HW transform functions; The ACCELERATED_COMPOSITING code path is really what you want. This is exactly what the ACCELERATED_COMPOSITING code path does. There is currently a Core Animation backend for Mac (GraphicsLayerCA.mm); you'd have to write a backend for your compositing system if you wish to use this code path. Does this handle the CSS transforms as well ? Yes. It also allows for 3D transforms, and hardware acceleration transitions and animations of certain CSS properties. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to interrupt Webkit Dump Render Tree output
Thank you.
So to get absolute co-ordinates of each Render Object, I need to do
something like:
int absolute_x = 0;
int absolute_y = 0;
parent = renderObject.getParent()
while (parent != RenderBody) {
absolute_x += parent.getX();
absolute_y += parent.getY();
}
Is that right?
Thank you.
On Sun, May 31, 2009 at 3:11 PM, Eric Seidel wrote:
> To expand Darin's answer: there are exceptions to the
> relative-to-containing-block rule. SVG results for example are absolute
> (mostly). There are also hacks the the DRT output, where we "lie" about
> metrics in order to keep consistent with historical results (to minimize the
> scope of a single patch). If you're trying to use DRT for anything other
> than testing, you will likely need to fork WebCore's RenderTreeAsText.cpp
> and SVGRenderTreeAsText.cpp substantially to fit your needs.
> -eric
> On Sun, May 31, 2009 at 10:19 AM, Darin Adler wrote:
>>
>> Coordinates in DumpRenderTree output are relative to the containing block,
>> not absolute.
>>
>> -- Darin
>>
>> ___
>> 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
Re: [webkit-dev] How to interrupt Webkit Dump Render Tree output
There is a method on RenderObject to get the correct absolute
coordinates of the renderer, which correctly takes transforms,
scrolling etc into account: RenderObject::localToAbsolute(). This is
not a trivial problem.
There are APIs exposed to JavaScript for this too: the offsetParent/
offsetX/offsetY, and getBoundingClientRect (see http://www.w3.org/TR/cssom-view/
); these, however, are not transform-aware.
What code are you in where you need these coordinates?
Simon
On Jun 1, 2009, at 10:00 AM, Lucius Fox wrote:
Thank you.
So to get absolute co-ordinates of each Render Object, I need to do
something like:
int absolute_x = 0;
int absolute_y = 0;
parent = renderObject.getParent()
while (parent != RenderBody) {
absolute_x += parent.getX();
absolute_y += parent.getY();
}
Is that right?
Thank you.
On Sun, May 31, 2009 at 3:11 PM, Eric Seidel
wrote:
To expand Darin's answer: there are exceptions to the
relative-to-containing-block rule. SVG results for example are
absolute
(mostly). There are also hacks the the DRT output, where we "lie"
about
metrics in order to keep consistent with historical results (to
minimize the
scope of a single patch). If you're trying to use DRT for anything
other
than testing, you will likely need to fork WebCore's
RenderTreeAsText.cpp
and SVGRenderTreeAsText.cpp substantially to fit your needs.
-eric
On Sun, May 31, 2009 at 10:19 AM, Darin Adler
wrote:
Coordinates in DumpRenderTree output are relative to the
containing block,
not absolute.
-- Darin
___
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
We should probably discuss this point on the whatwg list, but I'll give you my understanding of why this is desirable: 1) Since SharedWorkers aren't explicitly tied to a specific Document, it doesn't make sense to have them possibly get loaded from an out-of-date version of the app cache. If you have two separate documents running from different caches, it's weird (and indeterminate) if the version of the cache used to load the SharedWorker script is dependent on which one happens to call "new SharedWorker()" first. 2) Since SharedWorkers may outlive a given document, it makes sense to allow them to manage their own appcache state, especially once we start supporting PersistentWorkers (which may run for days, weeks, or years). 3) SharedWorkers may have a different criteria determining when it wants to update its app cache. As for what happens to a SharedWorker whose cache was updated? My presumption is that all future resource loads would use that cache. At that point, the SharedWorker has a few different things it could do: - Reload all of its scripts again using importScripts(). This implies that its script loading is idempotent, but that's not too hard to do. - Send messages to all of its client documents letting it know that it is shutting down, then invoke close() to shut itself down. The client documents can re-create the SharedWorker the next time they want one. This is inherently race-y, though, since you can't easily coordinate the shutdown of the worker with instantiations of new ones. - Do nothing at all -atw 2009/6/1 Alexey Proskuryakov > > 22.05.2009, в 3:20, Drew Wilson написал(а): > > >- SharedWorkers have explicit access to the ApplicationCache APIs, >while dedicated Workers merely inherit the ApplicationCache from their >parent window. > > What is the use case for this? It doesn't seem useful to me - to invoke > update explicitly, one normally needs to have UI anyway, at which point it's > much easier to call update() directly from a page. > > A tangentially related question: what will happen to a SharedWorker whose > cache got updated? Will the repository use a new source for new instances, > while the old ones will continue to run? Looks like there is a significant > potential for mistakes here, as scripts won't normally expect several > instances of the same SharedWorker to be active. > > - WBR, Alexey Proskuryakov > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Universal build options
Hi, I've searched high and low for an answer to this, so many apologies if it's a FAQ, but I can't find a resolution anywhere. I've noticed the --universal build option for WebKit no longer works, how do I do a universal build now? Thanks so much MT ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
01.06.2009, в 22:37, Drew Wilson написал(а): 1) Since SharedWorkers aren't explicitly tied to a specific Document, it doesn't make sense to have them possibly get loaded from an out-of-date version of the app cache. If you have two separate documents running from different caches, it's weird (and indeterminate) if the version of the cache used to load the SharedWorker script is dependent on which one happens to call "new SharedWorker()" first. I don't see how exposing DOMApplicationCache methods to workers can help this - a worker will only be able to call DOMApplicationCache.update() after it has started, which is too late. Besides, won't the document using an old version of cache break if a newer SharedWorker is suddenly returned to it? The main idea of appcache is that all application resources are versioned, so if we see SharedWorkers as part of application, they should use the same cache version. And if they are independent entities with a stable API, using an out of date version for a while cannot hurt. As for what happens to a SharedWorker whose cache was updated? My presumption is that all future resource loads would use that cache. At that point, the SharedWorker has a few different things it could do: Reload all of its scripts again using importScripts(). This implies that its script loading is idempotent, but that's not too hard to do. Send messages to all of its client documents letting it know that it is shutting down, then invoke close() to shut itself down. The client documents can re-create the SharedWorker the next time they want one. This is inherently race-y, though, since you can't easily coordinate the shutdown of the worker with instantiations of new ones. Do nothing at all All of these options seem quite dangerous - it may be difficult for JS authors to write applications that won't break at update time. A document can reload itself after updating, but SharedWorkers do not have a way to reload themselves. As you mentioned, they can reload imported scripts (but the main script will remain the same, which would be inconsistent). Or they can shut down and ask a document to re- create themselves - at which point, we can as well say that the document can update the cache. Interaction of SharedWorkers and appcache, explicit or not, sounds like a major issue to me. It can significantly affect the design (or even make SharedWorkers not worth being added, if no acceptable solution is found). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
2009/6/1 Alexey Proskuryakov > > 01.06.2009, в 22:37, Drew Wilson написал(а): > > 1) Since SharedWorkers aren't explicitly tied to a specific Document, it > doesn't make sense to have them possibly get loaded from an out-of-date > version of the app cache. If you have two separate documents running from > different caches, it's weird (and indeterminate) if the version of the cache > used to load the SharedWorker script is dependent on which one happens to > call "new SharedWorker()" first. > > > I don't see how exposing DOMApplicationCache methods to workers can help > this - a worker will only be able to call DOMApplicationCache.update() > after it has started, which is too late. > Not sure why that is "too late"? Can you clarify? > > Besides, won't the document using an old version of cache break if a newer > SharedWorker is suddenly returned to it? The main idea of appcache is that > all application resources are versioned, so if we see SharedWorkers as part > of application, they should use the same cache version. And if they are > independent entities with a stable API, using an out of date version for a > while cannot hurt. > > Why would a document using an old version of cache break if a newer SharedWorker is returned? Why is that any more of a problem than a document using a new version of cache breaking if an older SharedWorker is returned, which is what would happen if SharedWorkers inherited appcache from the first document that instantiated them? It seems like there are several easy options available to apps: 1) Change the name of the shared worker if a non-backward-compatible change needs to be made to the worker script (so new documents don't share the same worker instance as old documents) 2) When updates are available, coordinate updates with all documents so everyone updates at once, possibly exiting the SharedWorker. > > As for what happens to a SharedWorker whose cache was updated? My > presumption is that all future resource loads would use that cache. At that > point, the SharedWorker has a few different things it could do: > >- Reload all of its scripts again using importScripts(). This implies >that its script loading is idempotent, but that's not too hard to do. >- Send messages to all of its client documents letting it know that it >is shutting down, then invoke close() to shut itself down. The client >documents can re-create the SharedWorker the next time they want one. This >is inherently race-y, though, since you can't easily coordinate the > shutdown >of the worker with instantiations of new ones. >- Do nothing at all > > All of these options seem quite dangerous - it may be difficult for JS > authors to write applications that won't break at update time. > It might be tricky, although any application that does dynamic JS loading has to deal with versioning issues already. This is not particularly different. > > > A document can reload itself after updating, but SharedWorkers do not have > a way to reload themselves. As you mentioned, they can reload imported > scripts (but the main script will remain the same, which would be > inconsistent). > Why can't they reload the main script? Again, there's a need to be idempotent if you need to maintain some cached state, but it's not totally impossible. > Or they can shut down and ask a document to re-create themselves - at which > point, we can as well say that the document can update the cache. > I'm not arguing against this, I just don't see how it works when you have multiple documents each of which are running from different versions of the app cache, where the shared worker itself is attached to some arbitrary instance. > > Interaction of SharedWorkers and appcache, explicit or not, sounds like a > major issue to me. It can significantly affect the design (or even make > SharedWorkers not worth being added, if no acceptable solution is found). > My design doc just reflects the current spec - I don't really intend to be the defender of said spec. As I said previously, I think this is the wrong venue for us to describe issues with the spec - we should do it on the whatwg list to include other stakeholders. I'd be happy to start that conversation on the whatwg list, but to be honest I don't think I'm quite understanding what your objections to the current spec are. Would you mind kicking off that discussion with whatwg, outlining your concerns? -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Universal build options
On 2009-06-01, at 11:45, Moray Taylor wrote: Hi, I've searched high and low for an answer to this, so many apologies if it's a FAQ, but I can't find a resolution anywhere. I've noticed the --universal build option for WebKit no longer works, how do I do a universal build now? The --universal option was removed as the name was misleading and it was almost never useful. You can specify which architectures you'd like to build for by overriding two Xcode configuration settings on the build-webkit command-line: build-webkit ONLY_ACTIVE_ARCH=NO ARCHS="i386 ppc" You can adjust the value of ARCHS to suit your preference. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] embedding WebKit in MFC application
Hi Martin, I have updated my MFC port of the Apple example program 'CallJS'. You can grab this example project (http://files.me.com/bfulgham/socw2n). This might be more convenient because it includes a built copy of WebKit and the various support DLLs. It uses the newer API call "WebKitCreateInstance", which removes a lot of the issues with having to register the DLLs or properly configure the manifest file to use the WebKit.dll. I hope that helps! -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
How workers and appcaches interact has been discussed on the WHATWG list. Ian's "Worker feedback" message on 3/27/09 tried to tie things up for the time being. I think where he left things was a reasonable stepping stone, although the answers to the questions being asked here about updates were not entirely resolved. > What is the use case for this? It doesn't seem useful to me - to invoke > update explicitly, one > normally needs to have UI anyway, at which point it's much easier to call > update() directly from a > page. The use case are workers that can be considered "faceless applications". They are versioned independently of user interfaces that make use of them thru a stable message based API. > A tangentially related question: what will happen to a SharedWorker whose > cache got updated? > Will the repository use a new source for new instances, while the old ones > will continue to run? I think the intent of the current spec is that a new instance would not be created provided there is an existing instance already running. How to reload an existing worker to utilize new resources in an updated cache was left as an exercise to the reader. At least that's my understanding of the current spec. 2009/6/1 Drew Wilson : > > > 2009/6/1 Alexey Proskuryakov >> >> 01.06.2009, в 22:37, Drew Wilson написал(а): >> >> 1) Since SharedWorkers aren't explicitly tied to a specific Document, it >> doesn't make sense to have them possibly get loaded from an out-of-date >> version of the app cache. If you have two separate documents running from >> different caches, it's weird (and indeterminate) if the version of the cache >> used to load the SharedWorker script is dependent on which one happens to >> call "new SharedWorker()" first. >> >> I don't see how exposing DOMApplicationCache methods to workers can help >> this - a worker will only be able to call DOMApplicationCache.update() >> after it has started, which is too late. > > Not sure why that is "too late"? Can you clarify? > >> >> Besides, won't the document using an old version of cache break if a newer >> SharedWorker is suddenly returned to it? The main idea of appcache is that >> all application resources are versioned, so if we see SharedWorkers as part >> of application, they should use the same cache version. And if they are >> independent entities with a stable API, using an out of date version for a >> while cannot hurt. > > Why would a document using an old version of cache break if a newer > SharedWorker is returned? Why is that any more of a problem than a document > using a new version of cache breaking if an older SharedWorker is returned, > which is what would happen if SharedWorkers inherited appcache from the > first document that instantiated them? > It seems like there are several easy options available to apps: > 1) Change the name of the shared worker if a non-backward-compatible change > needs to be made to the worker script (so new documents don't share the same > worker instance as old documents) > 2) When updates are available, coordinate updates with all documents so > everyone updates at once, possibly exiting the SharedWorker. > >> >> As for what happens to a SharedWorker whose cache was updated? My >> presumption is that all future resource loads would use that cache. At that >> point, the SharedWorker has a few different things it could do: >> >> Reload all of its scripts again using importScripts(). This implies that >> its script loading is idempotent, but that's not too hard to do. >> Send messages to all of its client documents letting it know that it is >> shutting down, then invoke close() to shut itself down. The client documents >> can re-create the SharedWorker the next time they want one. This is >> inherently race-y, though, since you can't easily coordinate the shutdown of >> the worker with instantiations of new ones. >> Do nothing at all >> >> All of these options seem quite dangerous - it may be difficult for JS >> authors to write applications that won't break at update time. > > It might be tricky, although any application that does dynamic JS loading > has to deal with versioning issues already. This is not particularly > different. > >> >> >> >> A document can reload itself after updating, but SharedWorkers do not have >> a way to reload themselves. As you mentioned, they can reload imported >> scripts (but the main script will remain the same, which would be >> inconsistent). > > Why can't they reload the main script? Again, there's a need to be > idempotent if you need to maintain some cached state, but it's not totally > impossible. > >> >> Or they can shut down and ask a document to re-create themselves - at >> which point, we can as well say that the document can update the cache. > > I'm not arguing against this, I just don't see how it works when you have > multiple documents each of which are running from different versions of the > app cache, where the shared worker itself is attached to some
[webkit-dev] Security Origins
I have 2 questions about SecurityOrigins. First of all, in SecurityOrigin::databaseIdentifier() (in http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.h) the following comment appears: "Serialize the security origin for storage in the database. This format is deprecated and should be used only for compatibility with old databases; use toString() and createFromString() instead." This was done in http://trac.webkit.org/changeset/32597 Despite the comments in the change log, I don't fully understand what the intention here is. DatabaseTracker and LocalStorage still use databaseIdentifier() which makes sense since, unless I'm totally missing something, the toString() format produces file names that are invalid on most file systems. At the same time, databaseIdentifier omits some of the logic found in toString (which might be the cause of bugs like https://bugs.webkit.org/show_bug.cgi?id=20701 ...I haven't confirmed yet). So, maybe instead of databaseIdentifier() being "deprecated", it should be updated to be more like a toString that uses file system safe characters? In addition, the creation of SecurityOrigin objects doesn't quite seem right. There are many places (like in DatabaseTracker) where security origins are created based on the file, port, and protocol. This is fine when all you're doing is .equals (which the HashMap's HashArg=SecurityOriginHash prarmeter does for you), but it seems like it could be inefficient (many SecurityOrigin objects describing the same origin) and could potentially lead to bugs (since not all of the properties are serialized during toString()/databaseIdentifier()). It's surprising to me that there isn't one central store of SecurityOrigin objects (maybe with weak references?) to eliminate the possibility of 2 SecurityOrigin objects describing the same origin. In general, I suppose I'm just trying to understand the thought behind SecurityOrigin objects and how they're used in the source code...because it doesn't seem very natural to me. Thanks, Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
One more thing I'd follow up with is if we were to have a SharedWorker just inherit an applicationcache from the first document that creates it, what happens after that document closes? How can the SharedWorker update its application cache if an update becomes available, since the only document associated with that cache is now closed? -atw 2009/6/1 Michael Nordman > How workers and appcaches interact has been discussed on the WHATWG > list. Ian's "Worker feedback" message on 3/27/09 tried to tie things > up for the time being. I think where he left things was a reasonable > stepping stone, although the answers to the questions being asked here > about updates were not entirely resolved. > > > What is the use case for this? It doesn't seem useful to me - to invoke > update explicitly, one > > normally needs to have UI anyway, at which point it's much easier to call > update() directly from a > > page. > > The use case are workers that can be considered "faceless > applications". They are versioned independently of user interfaces > that make use of them thru a stable message based API. > > > A tangentially related question: what will happen to a SharedWorker whose > cache got updated? > > Will the repository use a new source for new instances, while the old > ones will continue to run? > > I think the intent of the current spec is that a new instance would > not be created provided there is an existing instance already running. > How to reload an existing worker to utilize new resources in an > updated cache was left as an exercise to the reader. > > At least that's my understanding of the current spec. > > > 2009/6/1 Drew Wilson : > > > > > > 2009/6/1 Alexey Proskuryakov > >> > >> 01.06.2009, в 22:37, Drew Wilson написал(а): > >> > >> 1) Since SharedWorkers aren't explicitly tied to a specific Document, it > >> doesn't make sense to have them possibly get loaded from an out-of-date > >> version of the app cache. If you have two separate documents running > from > >> different caches, it's weird (and indeterminate) if the version of the > cache > >> used to load the SharedWorker script is dependent on which one happens > to > >> call "new SharedWorker()" first. > >> > >> I don't see how exposing DOMApplicationCache methods to workers can help > >> this - a worker will only be able to call DOMApplicationCache.update() > >> after it has started, which is too late. > > > > Not sure why that is "too late"? Can you clarify? > > > >> > >> Besides, won't the document using an old version of cache break if a > newer > >> SharedWorker is suddenly returned to it? The main idea of appcache is > that > >> all application resources are versioned, so if we see SharedWorkers as > part > >> of application, they should use the same cache version. And if they are > >> independent entities with a stable API, using an out of date version for > a > >> while cannot hurt. > > > > Why would a document using an old version of cache break if a newer > > SharedWorker is returned? Why is that any more of a problem than a > document > > using a new version of cache breaking if an older SharedWorker is > returned, > > which is what would happen if SharedWorkers inherited appcache from the > > first document that instantiated them? > > It seems like there are several easy options available to apps: > > 1) Change the name of the shared worker if a non-backward-compatible > change > > needs to be made to the worker script (so new documents don't share the > same > > worker instance as old documents) > > 2) When updates are available, coordinate updates with all documents so > > everyone updates at once, possibly exiting the SharedWorker. > > > >> > >> As for what happens to a SharedWorker whose cache was updated? My > >> presumption is that all future resource loads would use that cache. At > that > >> point, the SharedWorker has a few different things it could do: > >> > >> Reload all of its scripts again using importScripts(). This implies that > >> its script loading is idempotent, but that's not too hard to do. > >> Send messages to all of its client documents letting it know that it is > >> shutting down, then invoke close() to shut itself down. The client > documents > >> can re-create the SharedWorker the next time they want one. This is > >> inherently race-y, though, since you can't easily coordinate the > shutdown of > >> the worker with instantiations of new ones. > >> Do nothing at all > >> > >> All of these options seem quite dangerous - it may be difficult for JS > >> authors to write applications that won't break at update time. > > > > It might be tricky, although any application that does dynamic JS loading > > has to deal with versioning issues already. This is not particularly > > different. > > > >> > >> > >> > >> A document can reload itself after updating, but SharedWorkers do not > have > >> a way to reload themselves. As you mentioned, they can reload imported > >> scripts (but the main script will remain the
Re: [webkit-dev] Security Origins
Hi Jeremy, Some of this has evolved and could likely be cleaned up. 2009/6/1 Jeremy Orlow : > First of all, in SecurityOrigin::databaseIdentifier() (in > http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.h) the > following comment appears: "Serialize the security origin for storage in the > database. This format is deprecated and should be used only for compatibility > with old databases; use toString() and createFromString() instead." This was > done in http://trac.webkit.org/changeset/32597 There are a bunch of problems with SecurityOrigin::databaseIdentifier(), not the least of which is that "_" can't really be used as a delimiter because some intranet host names contain the character in their names. I'd rather we didn't used databaseIdentifier() and had a single string representation we used everywhere. > Despite the comments in the change log, I don't fully understand what the > intention here is. DatabaseTracker and LocalStorage still use > databaseIdentifier() which makes sense since, unless I'm totally missing > something, the toString() format produces file names that are invalid on most > file systems. I don't see why these string representations need to be used for file names. The advantages of the toString() serialization are (1) we need it for postMessage and cross-origin XMLHttpRequest, and (2) we already have an awesome parser for it called KURL. > At the same time, databaseIdentifier omits some of the logic found in >toString (which might be the cause of bugs like >https://bugs.webkit.org/show_bug.cgi?id=20701 ...I haven't confirmed yet). I'll look at that bug once I have Internet access (currently on the train). > So, maybe instead of databaseIdentifier() being "deprecated", it should be > updated to be more like a toString that uses file system safe characters? Late time I looked into this, I was told we couldn't change databaseIdentifier() because users had files stored on their computer that depended on the serialization. > In addition, the creation of SecurityOrigin objects doesn't quite seem > right. There are many places (like in DatabaseTracker) where security > origins are created based on the file, port, and protocol. This is fine when > all you're doing is .equals (which the HashMap's HashArg=SecurityOriginHash > prarmeter does for you), but it seems like it could be inefficient (many > SecurityOrigin objects describing the same origin) and could potentially lead > to bugs (since not all of the properties are serialized during > toString()/databaseIdentifier()). I suspect we can improve this. > It's surprising to me that there isn't one central store of SecurityOrigin > objects (maybe with weak references?) to eliminate the possibility of 2 > SecurityOrigin objects describing the same origin. The problem is that SecurityOrigin objects are mutable. For example, a SecurityOrigin mutates if you set its document.domain property (called "domain"). Also, certain SecurityOrigin objects might be granted certain privileges, and we might not be able to do that if everyone shared the same object. > In general, I suppose I'm just trying to understand the thought behind > SecurityOrigin objects and how they're used in the source code...because it > doesn't seem very natural to me. It might be productive to invent a class "StorageOrigin" or some such that is immutable, and therefore can be shared and moved across threads. That way the storage system wouldn't be tempted to use SecurityOrigin features that don't make sense for storage (e.g., grantLoadLocalResources). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security Origins
On Mon, Jun 1, 2009 at 3:50 PM, Jeremy Orlow wrote: > I have 2 questions about SecurityOrigins. > > > First of all, in SecurityOrigin::databaseIdentifier() (in > http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.h) the > following comment appears: "Serialize the security origin for storage in the > database. This format is deprecated and should be used only for > compatibility with old databases; use toString() and createFromString() > instead." This was done in http://trac.webkit.org/changeset/32597 > > Despite the comments in the change log, I don't fully understand what the > intention here is. DatabaseTracker and LocalStorage still use > databaseIdentifier() which makes sense since, unless I'm totally missing > something, the toString() format produces file names that are invalid on > most file systems. At the same time, databaseIdentifier omits some of the > logic found in toString (which might be the cause of bugs like > https://bugs.webkit.org/show_bug.cgi?id=20701 ...I haven't confirmed yet). > > So, maybe instead of databaseIdentifier() being "deprecated", it should be > updated to be more like a toString that uses file system safe characters? > It is deprecated in the sense that only Database code should use it. We can't make Database code use toString() because there are existing clients that depend on the identifier to remain the same. > In addition, the creation of SecurityOrigin objects doesn't quite seem > right. There are many places (like in DatabaseTracker) where security > origins are created based on the file, port, and protocol. This is fine > when all you're doing is .equals (which the HashMap's > HashArg=SecurityOriginHash prarmeter does for you), but it seems like it > could be inefficient (many SecurityOrigin objects describing the same > origin) and could potentially lead to bugs (since not all of the properties > are serialized during toString()/databaseIdentifier()). > > It's surprising to me that there isn't one central store of SecurityOrigin > objects (maybe with weak references?) to eliminate the possibility of 2 > SecurityOrigin objects describing the same origin. > I suspect SecurityOrigins can be optimized, but as of yet they have not appeared on profiles. I would like to improve SecurityOrigins to better represent the concepts of effective script origin and origins representing resources more effectively. > > > In general, I suppose I'm just trying to understand the thought behind > SecurityOrigin objects and how they're used in the source code...because it > doesn't seem very natural to me. > SecurityOrigin was created to cleanup the way we do same-origin checks in the JavaScript bindings, and as such, carry some of that baggage (eg. domain relaxing). The main design constraint then was that it was a cheap compare for two origins representing the same document (pointer compare) as that is common case. The code evolved from there. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security Origins
On Mon, Jun 1, 2009 at 7:35 PM, Sam Weinig wrote: > > > On Mon, Jun 1, 2009 at 3:50 PM, Jeremy Orlow wrote: > >> I have 2 questions about SecurityOrigins. >> >> >> First of all, in SecurityOrigin::databaseIdentifier() (in >> http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.h) the >> following comment appears: "Serialize the security origin for storage in the >> database. This format is deprecated and should be used only for >> compatibility with old databases; use toString() and createFromString() >> instead." This was done in http://trac.webkit.org/changeset/32597 >> >> Despite the comments in the change log, I don't fully understand what the >> intention here is. DatabaseTracker and LocalStorage still use >> databaseIdentifier() which makes sense since, unless I'm totally missing >> something, the toString() format produces file names that are invalid on >> most file systems. At the same time, databaseIdentifier omits some of the >> logic found in toString (which might be the cause of bugs like >> https://bugs.webkit.org/show_bug.cgi?id=20701 ...I haven't confirmed >> yet). >> >> So, maybe instead of databaseIdentifier() being "deprecated", it should be >> updated to be more like a toString that uses file system safe characters? >> > > It is deprecated in the sense that only Database code should use it. We > can't make Database code use toString() because there are existing clients > that depend on the identifier to remain the same. > I don't think this is an issue (will comment further later on), but does this mean there's no migration strategy _if_ it was found that that names needed to change in the future? In other words, does this mean that the current format will need to be grandfathered in "forever"? > > >> In addition, the creation of SecurityOrigin objects doesn't quite seem >> right. There are many places (like in DatabaseTracker) where security >> origins are created based on the file, port, and protocol. This is fine >> when all you're doing is .equals (which the HashMap's >> HashArg=SecurityOriginHash prarmeter does for you), but it seems like it >> could be inefficient (many SecurityOrigin objects describing the same >> origin) and could potentially lead to bugs (since not all of the properties >> are serialized during toString()/databaseIdentifier()). >> >> It's surprising to me that there isn't one central store of SecurityOrigin >> objects (maybe with weak references?) to eliminate the possibility of 2 >> SecurityOrigin objects describing the same origin. >> > > I suspect SecurityOrigins can be optimized, but as of yet they have not > appeared on profiles. I would like to improve SecurityOrigins to better > represent the concepts of effective script origin and origins representing > resources more effectively. > > >> >> >> In general, I suppose I'm just trying to understand the thought behind >> SecurityOrigin objects and how they're used in the source code...because it >> doesn't seem very natural to me. >> > > SecurityOrigin was created to cleanup the way we do same-origin checks in > the JavaScript bindings, and as such, carry some of that baggage (eg. domain > relaxing). The main design constraint then was that it was a cheap compare > for two origins representing the same document (pointer compare) as that is > common case. The code evolved from there. > Makes sense. Note that SecurityOrigin::equal does not currently do a fast path check of "this == other" (to just do a pointer compare as you mentioned) so this is probably low hanging fruit to make things a bit faster. (Though, as you said, it's not showing up on current profiles...so it's probably not a huge deal.) On Mon, Jun 1, 2009 at 7:09 PM, Adam Barth wrote: > Hi Jeremy, > > Some of this has evolved and could likely be cleaned up. > > 2009/6/1 Jeremy Orlow : > > First of all, in SecurityOrigin::databaseIdentifier() (in > http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.h) the > following comment appears: "Serialize the security origin for storage in the > database. This format is deprecated and should be used only for > compatibility with old databases; use toString() and createFromString() > instead." This was done in http://trac.webkit.org/changeset/32597 > > There are a bunch of problems with > SecurityOrigin::databaseIdentifier(), not the least of which is that > "_" can't really be used as a delimiter because some intranet host > names contain the character in their names. I'd rather we didn't used > databaseIdentifier() and had a single string representation we used > everywhere. If this is the only issue, the parsing code could work around it. There are 3 parts to the identifier: the protocol (should never have a _ in it, right?), the domain, and the port (once again, should never have a _). It seems as though the parsing code should look for the first _, the last _, and then assume everything in the middle is the domain. > > > Despite the comments in the c
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 1:29, Michael Nordman написал(а): What is the use case for this? It doesn't seem useful to me - to invoke update explicitly, one normally needs to have UI anyway, at which point it's much easier to call update() directly from a page. The use case are workers that can be considered "faceless applications". They are versioned independently of user interfaces that make use of them thru a stable message based API. Is it really possible for a SharedWorker to be versioned independently from UI? When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). So, its source always matches the UI version. Even if there is a newer version of appcache already loaded, the document's one will be used for loading subresources. When a worker's script is referenced from several appcaches, this becomes somewhat trickier. As Andrew correctly mentioned, the version used will depend on which application was the first to construct the SharedWorker. But how is it a problem if we require SharedWorkers to implement a stable messaging API? Given that SharedWorkers are versioned together with UI, and that loading a new main resource in UI always invokes update process, I'm not sure if there are any use cases that require workers to call update() on their own. This is quite similar to how faceless helpers in large native application suites work - I don't think that they ever check for updates, it's only done at application startup. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security Origins
On Mon, Jun 1, 2009 at 8:29 PM, Jeremy Orlow wrote: > If this is the only issue, the parsing code could work around it. There are > 3 parts to the identifier: the protocol (should never have a _ in it, > right?), the domain, and the port (once again, should never have a _). It > seems as though the parsing code should look for the first _, the last _, > and then assume everything in the middle is the domain. I don't know of any reason why a scheme can't have a _... If you'd like to change the parsing code to understand domains with a _ this way, I think that would be an improvement. > Doesn't seem like a top priority, but maybe it's worth filing a low priority > bug for it anyway. Although they are 2 somewhat distinct use cases and I > see the possibility for misuse and bad assumptions, I'm not terribly worried > about it. I think HTML 5 has notions of "origin" and "effective script origin" (or some such) that separate these two concepts. It might be worth syncing up our internal names with the spec to make these concepts more accessible to future developers. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 0:19, Drew Wilson написал(а): My design doc just reflects the current spec - I don't really intend to be the defender of said spec. As I said previously, I think this is the wrong venue for us to describe issues with the spec - we should do it on the whatwg list to include other stakeholders. Did my response to Michael Nordman's message make the nature of objections more clear? I'd be happy to start that conversation on the whatwg list, but to be honest I don't think I'm quite understanding what your objections to the current spec are. Would you mind kicking off that discussion with whatwg, outlining your concerns? I think that there is value in discussing this among WebKit developers, as we can talk about how the design corresponds to low level implementation details. This is always important, but it would create a communication barrier on other venues. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
