Re: [webkit-dev] Flaky test hit list
On Fri, Oct 1, 2010 at 12:03, Adam Barth aba...@webkit.org wrote: https://bugs.webkit.org/show_bug.cgi?id=46956 Unfortunately, it doesn't solve the whole problem. It does seem to reduce the flakiness by a lot though. Thanks! I think it might be race between DRT and pywebsocekt server, that is, DRT tries to run tests while pywebsocket server is still initializing and not yet ready to serve html. I'll try to fix pywebsocket to reduce initialization latency. -- ukai Adam On Thu, Sep 30, 2010 at 6:12 PM, Adam Barth aba...@webkit.org wrote: Currently the WebSocket tests are served over HTTP from the WebSocket server itself (which is written in Python). It looks like we can resolve the flakiness by serving the WebSocket tests from the normal Apache server that servers the rest of our HTTP tests. I'm going to work up a patch that does that. Please let me know if there's any reason we shouldn't make that change. Thanks, Adam On Thu, Sep 30, 2010 at 3:10 PM, Adam Barth aba...@webkit.org wrote: I'm investigating the websocket issue. It seems these tests are flaky because they time out. If you know about websockets, I'd appreciate any tips you have via #webkit. Adam On Wed, Sep 29, 2010 at 11:31 PM, Adam Barth aba...@webkit.org wrote: Tonight I wrote a new webkit-patch command for detecting flaky tests. Here the tests that have flaked out on the Snow Leopard (Tests) build bot during the last 2000 revisions. This makes a good hit list of tests to fix to reduce flakiness. (The worst offenders are at the bottom). Take aways: 1) compositing/geometry/limit-layer-bounds-transformed-overflow.html is by far the worst offender. 2) The websocket tests are ridiculously flaky. 3) The appcache tests also have a serious flakiness problem. I'll run the last 1 revisions over night and report on the results. Adam === Results === Occurances Test name 1 compositing/reflections/nested-reflection-animated.html 1 fast/css/font-face-download-error.html 1 fast/dom/collection-null-like-arguments.html 1 fast/history/history-subframe-with-name.html 1 fast/js/sputnik/Conformance/13_Function_Definition/13.2_Creating_Function_Objects/S13.2.2_A5_T1.html 1 fast/js/sputnik/Conformance/13_Function_Definition/13.2_Creating_Function_Objects/S13.2.2_A5_T2.html 1 fast/js/vardecl-preserve-arguments.html 1 http/tests/appcache/different-https-origin-resource-main.html 1 http/tests/appcache/fallback.html 1 http/tests/appcache/manifest-redirect.html 1 http/tests/appcache/origin-quota.html 1 http/tests/appcache/resource-redirect.html 1 http/tests/appcache/top-frame-3.html 1 http/tests/appcache/update-cache.html 1 http/tests/appcache/xhr-foreign-resource.html 1 http/tests/cache/subresource-expiration.html 1 http/tests/loading/basic-credentials-sent-automatically.html 1 http/tests/misc/uncacheable-script-repeated.html 1 http/tests/navigation/changing-frame-hierarchy-in-onload.html 1 http/tests/navigation/ping-cross-origin-from-https.html 1 http/tests/navigation/ping-cross-origin.html 1 http/tests/navigation/post-goback-same-url.html 1 http/tests/plugins/get-url.html 1 http/tests/plugins/npapi-response-headers.html 1 http/tests/plugins/third-party-cookie-accept-policy.html 1 http/tests/security/credentials-in-referer.html 1 http/tests/security/cross-frame-access-protocol-explicit-domain.html 1 inspector/debugger-pause-on-breakpoint.html 1 inspector/extensions-events.html 1 media/audio-constructor.html 1 media/video-currentTime-set.html 1 plugins/destroy-stream-twice.html 1 plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html 1 svg/custom/use-invalid-style.svg 1 transitions/transition-end-event-transform.html 1 websocket/tests/send.html 1 websocket/tests/simple-stress.html 1 websocket/tests/sub-protocol-with-space.html 1 websocket/tests/url-no-trailing-slash.html 1 websocket/tests/url-with-empty-query.html 1 websocket/tests/url-with-query.html 1 websocket/tests/websocket-pending-activity.html 1 websocket/tests/workers/close-in-onmessage-crash.html 2 http/tests/appcache/foreign-iframe-main.html 2 http/tests/appcache/local-content.html 2 http/tests/appcache/main-resource-hash.html 2 http/tests/appcache/non-html.xhtml 2 http/tests/appcache/reload.html 2 http/tests/css/css-image-loading.html 2 http/tests/plugins/cross-frame-object-access.html 2 http/tests/security/cross-frame-access-port-explicit-domain.html 2
Re: [webkit-dev] Flaky test hit list
On Thu, Sep 30, 2010 at 15:31, Adam Barth aba...@webkit.org wrote: Tonight I wrote a new webkit-patch command for detecting flaky tests. Here the tests that have flaked out on the Snow Leopard (Tests) build bot during the last 2000 revisions. This makes a good hit list of tests to fix to reduce flakiness. (The worst offenders are at the bottom). Take aways: 1) compositing/geometry/limit-layer-bounds-transformed-overflow.html is by far the worst offender. 2) The websocket tests are ridiculously flaky. AFAIK the websocket tests are not so flaky on chromium (*). I wonder this is because of difference in platform code, but seems not so flaky on Leopard too. So, I suspect issues in test fixtures of websocket test (e.g. failed to start up pywebsocket server)? (*) http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=websocket -- ukai 3) The appcache tests also have a serious flakiness problem. I'll run the last 1 revisions over night and report on the results. Adam === Results === Occurances Test name 1 compositing/reflections/nested-reflection-animated.html 1 fast/css/font-face-download-error.html 1 fast/dom/collection-null-like-arguments.html 1 fast/history/history-subframe-with-name.html 1 fast/js/sputnik/Conformance/13_Function_Definition/13.2_Creating_Function_Objects/S13.2.2_A5_T1.html 1 fast/js/sputnik/Conformance/13_Function_Definition/13.2_Creating_Function_Objects/S13.2.2_A5_T2.html 1 fast/js/vardecl-preserve-arguments.html 1 http/tests/appcache/different-https-origin-resource-main.html 1 http/tests/appcache/fallback.html 1 http/tests/appcache/manifest-redirect.html 1 http/tests/appcache/origin-quota.html 1 http/tests/appcache/resource-redirect.html 1 http/tests/appcache/top-frame-3.html 1 http/tests/appcache/update-cache.html 1 http/tests/appcache/xhr-foreign-resource.html 1 http/tests/cache/subresource-expiration.html 1 http/tests/loading/basic-credentials-sent-automatically.html 1 http/tests/misc/uncacheable-script-repeated.html 1 http/tests/navigation/changing-frame-hierarchy-in-onload.html 1 http/tests/navigation/ping-cross-origin-from-https.html 1 http/tests/navigation/ping-cross-origin.html 1 http/tests/navigation/post-goback-same-url.html 1 http/tests/plugins/get-url.html 1 http/tests/plugins/npapi-response-headers.html 1 http/tests/plugins/third-party-cookie-accept-policy.html 1 http/tests/security/credentials-in-referer.html 1 http/tests/security/cross-frame-access-protocol-explicit-domain.html 1 inspector/debugger-pause-on-breakpoint.html 1 inspector/extensions-events.html 1 media/audio-constructor.html 1 media/video-currentTime-set.html 1 plugins/destroy-stream-twice.html 1 plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html 1 svg/custom/use-invalid-style.svg 1 transitions/transition-end-event-transform.html 1 websocket/tests/send.html 1 websocket/tests/simple-stress.html 1 websocket/tests/sub-protocol-with-space.html 1 websocket/tests/url-no-trailing-slash.html 1 websocket/tests/url-with-empty-query.html 1 websocket/tests/url-with-query.html 1 websocket/tests/websocket-pending-activity.html 1 websocket/tests/workers/close-in-onmessage-crash.html 2 http/tests/appcache/foreign-iframe-main.html 2 http/tests/appcache/local-content.html 2 http/tests/appcache/main-resource-hash.html 2 http/tests/appcache/non-html.xhtml 2 http/tests/appcache/reload.html 2 http/tests/css/css-image-loading.html 2 http/tests/plugins/cross-frame-object-access.html 2 http/tests/security/cross-frame-access-port-explicit-domain.html 2 security/block-test.html 2 websocket/tests/bad-sub-protocol-non-ascii.html 2 websocket/tests/handshake-fail-by-sub-protocol-mismatch.html 2 websocket/tests/simple.html 2 websocket/tests/unicode.html 3 http/tests/appcache/cyrillic-uri.html 3 http/tests/appcache/deferred-events-delete-while-raising.html 3 http/tests/appcache/remove-cache.html 3 http/tests/appcache/top-frame-4.html 3 http/tests/navigation/image-load-in-unload-handler.html 3 websocket/tests/handshake-fail-by-cross-origin.html 3 websocket/tests/httponly-cookie.pl 3 websocket/tests/long-invalid-header.html 3 websocket/tests/sub-protocol.html 3 websocket/tests/url-with-query-for-no-query.html 4 fast/canvas/webgl/gl-object-get-calls.html 4 http/tests/navigation/anchor-basic.html 4 websocket/tests/bad-sub-protocol-control-chars.html 4
Re: [webkit-dev] Ancient patches in pending-review
On Fri, May 14, 2010 at 02:31, Alexey Proskuryakov a...@webkit.org wrote: 13.05.2010, в 10:19, David Levin написал(а): Should we just r- and ask that it wait for conceptual issues to be resolved in IETF spec review first (unless for some reason it is needed quickly and that takes too long)? I am not aware of any specific conceptual issues, just the fact that TCP connection closing is not as simple as some people think. It would take me more time to refresh my knowledge than I've been able to afford yet, but there is nothing here that should stop another reviewer. https://bugs.webkit.org/show_bug.cgi?id=35573 just adds CloseEvent, as http://html5.org/tools/web-apps-tracker?from=4816to=4817 Closing handshake that will set wasClean flag of CloseEvent will be implemented in https://bugs.webkit.org/show_bug.cgi?id=35721. Should I put these in one patch? -- ukai - WBR, Alexey Proskuryakov ___ 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] Python on the Tiger build bot
I heard on #webkit that the Tiger bot has been on Python 2.5 for some time, and found r+ for https://bugs.webkit.org/show_bug.cgi?id=38886 and https://bugs.webkit.org/show_bug.cgi?id=38822. I believe we have consensus to use Python 2.5 (or later) for webkit development environment. I tried to land autoinstalled pywebsocket 0.5 https://bugs.webkit.org/show_bug.cgi?id=38034 again, but get error on tiger bot when launching websocket server as below. Is python on the tiger bot still 2.3? I'm wondering why the script raises SyntaxError at with-statement, although it uses from __future__ import with_statement at the beginning of the same file. Doesn't python raise error when it tries to import with_statement, rather than it sees with statement later? Anyway, I just marked to skip websocket/tests on tiger for now, hoping python2.5 is available on tiger bot soon. This is log: http://build.webkit.org/builders/Tiger%20Intel%20Release/builds/11971/steps/layout-test/logs/stdio websocket/tests .Traceback (most recent call last): File WebKitTools/Scripts/new-run-webkit-websocketserver, line 38, in ? import webkitpy.layout_tests.port.websocket_server as websocket_server File /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py, line 241 with codecs.open(self._pidfile, w, ascii) as file: ^ SyntaxError: invalid syntax websocket/tests/bad-handshake-crash.html - failed . websocket/tests/bad-sub-protocol-control-chars.html - failed . websocket/tests/bad-sub-protocol-empty.html - failed . websocket/tests/bad-sub-protocol-non-ascii.html - failed . websocket/tests/bufferedAmount-after-close.html - failed . websocket/tests/close-on-navigate-new-location.html - failed . websocket/tests/close-on-unload-and-force-gc.html - failed . websocket/tests/close-on-unload-reference-in-parent.html - failed . websocket/tests/close-on-unload.html - failed . websocket/tests/cross-origin.html - failed . websocket/tests/error-detect.html - failed . websocket/tests/frame-length-longer-than-buffer.html - failed . websocket/tests/frame-length-skip.html - failed . websocket/tests/frame-lengths.html - failed . websocket/tests/handshake-error.html - failed . websocket/tests/handshake-fail-by-cross-origin.html - failed . websocket/tests/handshake-fail-by-sub-protocol-mismatch.html - failed . websocket/tests/httponly-cookie.pl - failed . websocket/tests/long-invalid-header.html - failed . websocket/tests/multiple-connections.html - failed Exiting early after 20 failures. 17934 tests run. 762.46s total testing time Traceback (most recent call last): File WebKitTools/Scripts/new-run-webkit-websocketserver, line 38, in ? import webkitpy.layout_tests.port.websocket_server as websocket_server File /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py, line 241 with codecs.open(self._pidfile, w, ascii) as file: ^ SyntaxError: invalid syntax -- ukai On Tue, May 11, 2010 at 15:07, Maciej Stachowiak m...@apple.com wrote: On May 10, 2010, at 11:01 PM, Eric Seidel wrote: On Mon, May 10, 2010 at 2:25 AM, Maciej Stachowiak m...@apple.com wrote: My feeling about requiring a higher Python version for Tiger remains this: I'd prefer that we provide an easy means to do the install of Python 2.6 (ideally a single script you can run, and ideally without affecting the system copy), rather than making every Tiger developer figure it out on their own. http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html For those of us who still need to support Tiger, it would be a huge hassle to have to figure out how to update Python manually to even run the layout tests. The fact that it's not a primary development platform doesn't mean that it's ok to add stumbling blocks to the development process. In fact, it kinda makes it less ok, because then it takes more work to shift gears when fixing a Tiger-specific bug. Provided: https://bugs.webkit.org/show_bug.cgi?id=38886 At minimum, there should be instructions here, and ideally the install should be one step: http://webkit.org/building/tools.html Provided: https://bugs.webkit.org/show_bug.cgi?id=38822 Yay thanks! (Will try to review these later if no one beats me.) Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MD5 in WebCore
Thanks for suggestion.
I'll add MD5 implementation in WTF, based on chrome's base/md5, which seems
came from sqlite public domain code. I believe this would be a
platform-independent implementation.
--
ukai
On Wed, Apr 21, 2010 at 04:58, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2010, at 11:48 AM, Michael Nordman wrote:
In webcore, should we use the same impl on all platforms rather than use
cryptdll on windows and md5.cc elsewhere?
For chrome, I don't think we can have a dependency between
WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit' also
doesn't work. How can we avoid replicating the code? I guess having
webcore's MD5 be platform specific could help us along those lines?
I'd rather use a platform-independent MD5 implementation in WebCore if
possible.
Since the MD5 code itself has (presumably) minimal dependencies, perhaps we
could put it in WTF. I don't know if that would help Chromium's dependency
issues.
Regards,
Maciej
On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
I'm implementing new protocol of WebSocket (
http://www.whatwg.org/specs/web-socket-protocol/ ).
Since it now requires MD5 in handshake, I wonder how I could add MD5 in
WebCore. For now, there is no MD5 in WebCore. It is in
WebKitTools/DumpRenderTree to get message digest of image file.
I'm thinking to add new header file as WebCore/platform/MD5.h, which
provides the following functions.
struct MD5_CTX;
void MD5_Init(MD5_CTX*);
void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
void MD5_Final(unsigned char hash[16], MD5_CTX*);
In Windows platform, it is implemented using Cryptdll.dll. Is it ok to
copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
or move?
In Mac platform, it is provided by CommonCrypto/CommonDigest.h with
#define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy this in
WebCore/platform/chromium, or add dependency to base from WebCore?
How about other ports? is it ok to link openssl or some other library?
(or use implementation used in chromium?)
I'm also wonder I need to put these functions in namespace WebCore.
If you put this code in WebCore, it should go in the WebCore namespace. I
think it would also be a good idea to turn the API into something more
WebCore-ish, something like:
namespace WebCore {
class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was MD5_Update ;
or maybe this should take a Vectoruint8_t?
Vectoruint8_t, 16 checksum(); // what was MD5_Final
};
}
(The key point being to match the coding style guidelines for names, but
it also seems better to use a class here instead of a struct and functions
that take a pointer to it.)
Regards,
Maciej
___
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] MD5 in WebCore
I'm implementing new protocol of WebSocket (
http://www.whatwg.org/specs/web-socket-protocol/ ).
Since it now requires MD5 in handshake, I wonder how I could add MD5 in
WebCore. For now, there is no MD5 in WebCore. It is in
WebKitTools/DumpRenderTree to get message digest of image file.
I'm thinking to add new header file as WebCore/platform/MD5.h, which
provides the following functions.
struct MD5_CTX;
void MD5_Init(MD5_CTX*);
void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
void MD5_Final(unsigned char hash[16], MD5_CTX*);
In Windows platform, it is implemented using Cryptdll.dll. Is it ok to
copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
or move?
In Mac platform, it is provided by CommonCrypto/CommonDigest.h with
#define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy this in
WebCore/platform/chromium, or add dependency to base from WebCore?
How about other ports? is it ok to link openssl or some other library? (or
use implementation used in chromium?)
I'm also wonder I need to put these functions in namespace WebCore.
Thanks in advance,
ukai
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Super-slow websocket tests
On Thu, Jan 14, 2010 at 10:34 AM, Alexey Proskuryakov a...@webkit.org wrote: On 13.01.2010, at 17:00, Darin Adler wrote: 6.87 secs: websocket/tests/frame-lengths.html This test verifies that packet size computation logic is correct for all message sizes from 0 to 1025. We've had bugs in this area before, and it's hard to ensure adequate coverage without testing all message sizes. I haven't checked if the bottleneck is server-side or client-side, and actually assumed that this is a reasonable time to make 1K connections. Sorry, I don't remember what bugs in this area. Can we do test only boundary case? 3.63 secs: websocket/tests/simple-stress.html This test sends a thousand of short messages simultaneously, and one huge one (256K). I think that it is an important stress test to keep. 1.18 secs: websocket/tests/bad-sub-protocol.html This test can be made faster by executing subtests in parallel. I'll do it: https://bugs.webkit.org/show_bug.cgi?id=33646 -- ukai - WBR, Alexey Proskuryakov ___ 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] Super-slow websocket tests
On Thu, Jan 14, 2010 at 12:29 PM, Alexey Proskuryakov a...@webkit.org wrote: 13.01.2010, в 19:16, Fumitoshi Ukai (鵜飼文敏) написал(а): 6.87 secs: websocket/tests/frame-lengths.html This test verifies that packet size computation logic is correct for all message sizes from 0 to 1025. We've had bugs in this area before, and it's hard to ensure adequate coverage without testing all message sizes. Sorry, I don't remember what bugs in this area. https://bugs.webkit.org/show_bug.cgi?id=30656 https://bugs.webkit.org/show_bug.cgi?id=32203 These bugs are length-based framing, which isn't used in normal websocket messaging yet. (we don't send these frames, and we should skip these frames). frame-lengths.html tries to send any length of text, but these messages are delivered with \xFF-terminated frame (frame-type 0x00), not with length-based frame (frame-type 0x80). So, I don't think frame-lengths.html would catch bugs something like above bugs... -- ukai Can we do test only boundary case? Perhaps. I'm not sure what case to consider being boundary. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebSocket threading design
Right now, WebSocket uses WebSocketChannel and SocketStreamHandle directly, but this might not work well if the WebSocket is running on another thread (i.e. worker threads). SocketStreamHandleCFNet is expected to run on loader process/main thread, so attachment 44393 in bug 32214 won't work well on Mac. Also, we'll want to share global data to maintain current opening channel to limit the number of opening channel to each destination in WebSocketChannel class. So, I propose to set thread boundary on the WebSocketChannel interface. I introduce ThreadableWebSocketChannel, which is abstract interface for WebSocketChannel, and ThreadableWebSocketChannelClientWrapper, which is ThreadSafeShared class to wrap WebSocketChannelClient. ThreadableWebSocketChannel::create() will create WebSocketChannel on the main thread, or create WorkerThreadableWebSocketChannel on the worker thread. WorkerThreadableWebSocketChannel has a bridge between the worker thread and the main thread. It uses WorkerLoaderProxy to communicate between the threads. WebSocketChannel and SocketStreamHandle always runs on the main thread. http://docs.google.com/View?id=dfm7gfvg_13drnxm3fn Is there anything else I should be careful about? Any comments are welcome. Thanks! ukai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: Hi, I'm against prefixing with webkit- because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. I think this captures the root of the disagreement. Personally, I would like to do something to send the message that WebSocket is still somewhat experimental. It's true that the spec has been in development for a long time. But we are only now seeing the first client-side and server-side implementations. A number of issues were discovered in that process, and I'd personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Historically, we haven't had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal. Anyway, getting back to the suggestions... I think it's reasonable at this point to indicate that the WebSocket protocol is somewhat experimental (probably more so than the API). I will recommend doing something along those lines for the next release of Safari. If we can get rough consensus within the WebKit community that we should label the protocol experimental, and how we should do so, then we can just make the change in WebKit and vendor releases will follow along. Here is an extended list of ideas (ones that I think are practically doable): 1) Change the URI schemes to webkit-ws and webkit-wss - the vendor prefix strategy. 2) Change the URI schemes to x-ws and x-wss - a vendor-independent experimental prefix. 3) Don't change the URI schemes at all, but communicate in some public way that the protocol is not completely locked down yet, and we are largely looking for early adopter feedback. We could do this in the form of a WebKit blog post, for example. And we could reinforce that in developer documentation for WebKit-based products. 4) Support both unprefixed and prefixed URI schemes, and in addition publicize that we will maintain compatibility for the prefixed URI scheme but the unprefixed version may have to change (combo of 3 and either 1 or 2). 5) Make the feature runtime switchable (using some semi-hidden UI) and off by default. I'd like to hear opinions on which of these is best. I vote option (3). Even if we keep current protocol stack with prefixed URI, I'm wondering any websocket server implementation will keep compatibility with procotol of our prefixed URI.. Or, if some websocket server implementation keeps compatible with prefixed URI, I believe it's worse situation for future. -- ukai I'd also like to hear if anyone feels that we should send the message that the WebSocket Protocol is production quality and we promise full compatibility going forward. Does anyone truly feel this way? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org/WebKit.git out of sync from svn repository?
On Sat, Nov 7, 2009 at 6:10 AM, William Siegrist wsiegr...@apple.comwrote: On Nov 5, 2009, at 8:32 PM, Fumitoshi Ukai (鵜飼文敏) wrote: I think svn has r50586 (accodring to trac.webkit.org), but git only pulls r50565now. Even I clone git repository from git://git.webkit.org/WebKit.git again, it only has r50565. Is it out of sync? We had syncing issues yesterday, but they look fixed now. Can you retry? It seems working now. Thanks! ukai -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
It is requested to be turned on at the beginning of Web Sockets implementation so that it will be tested as it is brought up. https://bugs.webkit.org/show_bug.cgi?id=27206 Is is ok to turn off by default from this point of view? On Tue, Oct 6, 2009 at 1:57 PM, Darin Fisher da...@chromium.org wrote: On Mon, Oct 5, 2009 at 9:54 PM, Mark Rowe mr...@apple.com wrote: On 2009-10-05, at 21:48, Darin Fisher wrote: It is a matter of our process that we do not change the configuration when promoting builds. The bits that passed the test get promoted. I'm happy to absorb this cost in the V8 bindings. I don't think it is important to solve this problem for the JSC bindings since there is not a consumer that yet needs the same. The present state of Web Sockets is that they're compiled in on Mac OS X but disabled via the runtime setting. This leads to them being detectable in the manner Sam mentioned. Either the compile-time setting needs to be fixed for Mac OS X or the runtime code fixed so that the feature is not detectable when disabled. I assume that we want regression testing of the feature so disabling it at compile time does not seem like the best idea. I guess it comes down to whether or not it's in good enough shape to be useful to web sites at this time. - Mark Agreed. As usual, I think each port should be able to choose when to expose the feature. -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] Runtime setting for incomplete features
So, is it fine to make WebSockets enable by default? For now, there are no SocketStreamHandle implementation. so even enabling WebSockets in Settings, it is the almost same that the feature is not available.. -- ukai On Tue, Oct 6, 2009 at 2:04 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 5, 2009, at 9:54 PM, Mark Rowe wrote: On 2009-10-05, at 21:48, Darin Fisher wrote: It is a matter of our process that we do not change the configuration when promoting builds. The bits that passed the test get promoted. I'm happy to absorb this cost in the V8 bindings. I don't think it is important to solve this problem for the JSC bindings since there is not a consumer that yet needs the same. The present state of Web Sockets is that they're compiled in on Mac OS X but disabled via the runtime setting. This leads to them being detectable in the manner Sam mentioned. Either the compile-time setting needs to be fixed for Mac OS X or the runtime code fixed so that the feature is not detectable when disabled. I assume that we want regression testing of the feature so disabling it at compile time does not seem like the best idea. I guess it comes down to whether or not it's in good enough shape to be useful to web sites at this time. I think WebSockets should be compiled in and enabled on Mac OS X. I don't think we even need a way to turn them off at runtime for non-Chromium ports. The policy we generally follow for nightly builds is that we enable new features unless they would create significant problems with normal browsing, or major security risk, for users of the nightlies. We do sometimes disable optional features shortly before branching WebKit for release (apparently unlike the Chromium process) and I don't believe we've ever had a bug caused by that. We certainly wouldn't ship a production build of WebKit on Mac OS X with a feature compiled in but disabled at runtime. Regards, Maciej ___ 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] HTML5 Web Socket Design Doc
Hi, On Mon, Jul 13, 2009 at 1:50 AM, Ojan Vafai o...@chromium.org wrote: You had mentioned that there were a couple people at Apple the intended to start working on WebSockets soonish, is that still the plan? If so, who should be CCed on the appropriate bugs? Ukai-san, I think the next step here it to file a bug at bugs.webkit.org and to start sending patches. Thanks for yoru advice. I've created patches to add websocket in WebKit (with gtk platform code). It misses several features of websocket (cookie, auth, tls, ..), but it works somehow and would be tracer bullet of websocket implementation. I'll file bugs and start sending patches. Thanks! Fumitoshi Ukai I'm not authority here, but you should try to get this up in pieces instead of getting the whole thing working on your end and then trying to get that all reviewed in one big chunk. Put it behind an ENABLE_WEBSOCKETS define so that it can be buggy (or even not compile) as you get the various bits in. Two patches that are easily separable: 1. The patch adding the ENABLE_WEBSOCKETS define 2. The patch adding DumpRenderTree support for testing websockets (along with whatever server component it will need) Anyone else on this list, feel free to chime in if I'm giving the wrong advice here. :) Ojan On Sat, Jul 11, 2009 at 9:23 AM, Ojan Vafaio...@chromium.org wrote: Maciej, You had mentioned that there were a couple people at Apple the intended to start working on WebSockets soonish, is that still the plan? If so, who should be CCed on the appropriate bugs? Ukai-san, I think the next step here it to file a bug at bugs.webkit.org and to start sending patches. I'm not authority here, but you should try to get this up in pieces instead of getting the whole thing working on your end and then trying to get that all reviewed in one big chunk. Put it behind an ENABLE_WEBSOCKETS define so that it can be buggy (or even not compile) as you get the various bits in. Two patches that are easily separable: 1. The patch adding the ENABLE_WEBSOCKETS define 2. The patch adding DumpRenderTree support for testing websockets (along with whatever server component it will need) Anyone else on this list, feel free to chime in if I'm giving the wrong advice here. :) Ojan On Mon, Jun 29, 2009 at 1:03 AM, Fumitoshi Ukai (鵜飼文敏)u...@chromium.org wrote: Hi, yuzo, tyoshino and ukai @chromium.org start working to implement HTML5 Web Socket and write design doc. http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Any comments? We'd welcome if you could give us feedback on our design doc. Thanks! Fumitoshi Ukai ___ 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] HTML5 Web Socket Design Doc
Hi, yuzo, tyoshino and ukai @chromium.org start working to implement HTML5 Web Socket and write design doc. http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Any comments? We'd welcome if you could give us feedback on our design doc. Thanks! Fumitoshi Ukai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
