Re: [webkit-dev] LocalStorage spec and structured cloning
You can't store much data in cookies and thus you're only shooting yourself in the foot with a bb gun. 5mb means you're shooting yourself in the foot with a real gun. And if you're allowing over 5mb, it's a bazooka. Anyway, I've written extensively about this many times on many different lists. Luckily for me, it doesn't look like I need to write yet again since it looks like I've convinced Jonas of my position. :-) J On Thu, Jun 2, 2011 at 10:04 PM, Alexey Proskuryakov a...@webkit.org wrote: I think that these shortcomings are also strengths. A synchronous localStorage is a drop-in replacement for cookies, which is a good thing to offer, and to encourage. Practically, if it's only cookies vs. IndexedDB (or SQL Database), I'd realistically choose the former for most code, and I'm sure that many Web developers would do the same. It doesn't matter all that much if developers encode to JSON themselves or the engine does that, but adding a little syntactic sugar seems beneficial. - WBR, Alexey Proskuryakov 02.06.2011, в 20:54, Darin Fisher написал(а): I'm concerned that implementing this will only encourage more use of localStorage. The API is very poor because it requires synchronous IO and synchronization between browser contexts, which may live on different threads. (Note: Chrome does not implement the required synchronization.) If we could fix localStorage to be asynchronous and transactional :-) then it'd be cool. Of course, one answer is that people should just use IndexedDB. FWIW, Jorlow (when he was still working on chrome) expressed similar sentiments. On Jun 2, 2011 4:13 PM, Maciej Stachowiak m...@apple.com wrote: Does anyone have an opinion on this Web Storage spec bug? The input of the WebKit community is desired. And probably Safari and Chrome folks in particular, if opinions differ. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that The getItem(key) method must return a structured clone of the current value associated with the given key. but all browsers I've tested return a string representation of the value instead. 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 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] LocalStorage spec and structured cloning
On Fri, Jun 3, 2011 at 1:40 AM, Jeremy Orlow jor...@chromium.org wrote: You can't store much data in cookies and thus you're only shooting yourself in the foot with a bb gun. 5mb means you're shooting yourself in the foot with a real gun. And if you're allowing over 5mb, it's a bazooka. ...and for this reason, Chromium will never give developers more than 5mb of localStorage space (even if we give them more space for other APIs). (I've lobbied for even reducing the space we hand out...not sure if that'll happen though.) Anyway, I've written extensively about this many times on many different lists. Luckily for me, it doesn't look like I need to write yet again since it looks like I've convinced Jonas of my position. :-) J On Thu, Jun 2, 2011 at 10:04 PM, Alexey Proskuryakov a...@webkit.orgwrote: I think that these shortcomings are also strengths. A synchronous localStorage is a drop-in replacement for cookies, which is a good thing to offer, and to encourage. Practically, if it's only cookies vs. IndexedDB (or SQL Database), I'd realistically choose the former for most code, and I'm sure that many Web developers would do the same. It doesn't matter all that much if developers encode to JSON themselves or the engine does that, but adding a little syntactic sugar seems beneficial. Also note that such syntactic sugar breaks compat. (There's a concise example in the bug.) I think it's best just to leave localStorage as is... J - WBR, Alexey Proskuryakov 02.06.2011, в 20:54, Darin Fisher написал(а): I'm concerned that implementing this will only encourage more use of localStorage. The API is very poor because it requires synchronous IO and synchronization between browser contexts, which may live on different threads. (Note: Chrome does not implement the required synchronization.) If we could fix localStorage to be asynchronous and transactional :-) then it'd be cool. Of course, one answer is that people should just use IndexedDB. FWIW, Jorlow (when he was still working on chrome) expressed similar sentiments. On Jun 2, 2011 4:13 PM, Maciej Stachowiak m...@apple.com wrote: Does anyone have an opinion on this Web Storage spec bug? The input of the WebKit community is desired. And probably Safari and Chrome folks in particular, if opinions differ. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that The getItem(key) method must return a structured clone of the current value associated with the given key. but all browsers I've tested return a string representation of the value instead. 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 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] Do we have a style preference about const member functions?
On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote: All functions passed to enclosingNodeOfType in htmlediting.cpp are such clients: Node* enclosingNodeOfType(const Position p, bool (*nodeIsOfType)(const Node*), EditingBoundaryCrossingRule rule) It takes a boolean function that takes const pointer to a DOM node. It is critical that nodeIsOfType does not modify DOM This points to a place where const does not work well. Having the single node pointer that is the argument to the function be const does not express “must not modify DOM”. If there was some way to express “must not modify DOM” that would be great, but that just expresses “must not modify this DOM node”. It happens that the predicate takes a node argument. You could imagine a similar function that takes a Range. You can see that that’s an even clearer. There’s no way to pass a range to a function and also say “must not modify DOM”. I don’t think const is a good way to express this. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?
On 10/6/10 8:00 PM, Darin Adler wrote: For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s now showing up in Apple’s Software Update for all Xcode users, I believe. I opened https://bugs.webkit.org/show_bug.cgi?id=62011 to get the web site updated to indicate = 3.2.4 is now required. Also noted that there should be an indication of whether XCode 4.x can be used for daily development. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Jun 3, 2011, at 7:50 AM, Darin Adler wrote: On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote: All functions passed to enclosingNodeOfType in htmlediting.cpp are such clients: Node* enclosingNodeOfType(const Position p, bool (*nodeIsOfType)(const Node*), EditingBoundaryCrossingRule rule) It takes a boolean function that takes const pointer to a DOM node. It is critical that nodeIsOfType does not modify DOM This points to a place where const does not work well. Having the single node pointer that is the argument to the function be const does not express “must not modify DOM”. If there was some way to express “must not modify DOM” that would be great, but that just expresses “must not modify this DOM node”. It happens that the predicate takes a node argument. You could imagine a similar function that takes a Range. You can see that that’s an even clearer. There’s no way to pass a range to a function and also say “must not modify DOM”. I don’t think const is a good way to express this. Are you referring to the fact that from a const Node* can be used to get non-const pointers to the Node's neighbors in the DOM, or something else? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cherry-Pick Bug Comments
Either (1) or (2) is fine. Please pick one and do it. The status quo is very annoying. Adam On Tue, May 31, 2011 at 6:58 AM, Ademar Reis ademar.r...@openbossa.org wrote: On Thu, May 26, 2011 at 7:54 PM, Eric Seidel e...@webkit.org wrote: I get a lot of these: Revision r86028 cherry-picked into qtwebkit-2.2 with commit 7e1bab1 http://gitorious.org/webkit/qtwebkit/commit/7e1bab1 as bug mail. Probably because I'm CC'd on a zillion bugs (and actually read my bug mail). This is probably the pot calling the kettle black, since I wrote many of the bots which comment daily on bugs... ...but, I'm wondering if we can do better? Would it better serve the cherry-picker's needs if we instead had a separate server to track revision - cherry-picks? Or bug ids - cherry-picks? (Like how the EWS bots store their status on queues.webkit.org and display it in little bubbles on bugs.webkit.org w/o commenting on the bugs.) I'm strongly supportive of all clients of webkit storing all of their bug-related data in bugs.webkit.org. It's better than the alternative (lots of data buried in old Radars, or Chromium bugs, etc.) Hi again. Just so that this thread doesn't die. I think we have two good proposals on the table: 1. Track cherry-pick info on an external server and add an iframe inside bugzilla, the same way EWS bots do. Pros: scalable, any vendor could add their own trackers (would it be interesting to add rdar:// comments using this same mechanism?) 2. Configure/hack bugzilla to allow the addition of comments without trigerring e-mails. Pros: small change, appears to be easy to implement - specially on my side ;-) Eric: how do we proceed from now? In the meanwhile, please be patient with the cherry-pick e-mails... As usual there will be a few of them this week (in average, something like 20-30 cherry-picks per week). Thanks, - Ademar -- Ademar de Souza Reis Jr. ademar.r...@openbossa.org Nokia Institute of Technology ___ 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] Do we have a style preference about const member functions?
On Jun 3, 2011, at 9:28 AM, Maciej Stachowiak wrote: On Jun 3, 2011, at 7:50 AM, Darin Adler wrote: On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote: All functions passed to enclosingNodeOfType in htmlediting.cpp are such clients: Node* enclosingNodeOfType(const Position p, bool (*nodeIsOfType)(const Node*), EditingBoundaryCrossingRule rule) It takes a boolean function that takes const pointer to a DOM node. It is critical that nodeIsOfType does not modify DOM This points to a place where const does not work well. Having the single node pointer that is the argument to the function be const does not express “must not modify DOM”. If there was some way to express “must not modify DOM” that would be great, but that just expresses “must not modify this DOM node”. It happens that the predicate takes a node argument. You could imagine a similar function that takes a Range. You can see that that’s an even clearer. There’s no way to pass a range to a function and also say “must not modify DOM”. I don’t think const is a good way to express this. Are you referring to the fact that from a const Node* can be used to get non-const pointers to the Node's neighbors in the DOM, or something else? Sort of. From a const Node* you can get: - a non-const pointer to a parent, sibling, or child - a non-const pointer to the document - a non-const pointer to the renderer - a non-const pointer to the style - a non-const pointer to various shadow-related ancestors and hosts That’s one problem. Extending the const-ness of the node to mean constness of everything you can get through all these pointers would be a big task, and it’s not clear it would be worthwhile. Further, from the document you can get to the frame and things like the selection controller. Experience with the C++ standard library taught me that a constant pointer to something within a collection is a difficult concept to model with const. The key example here is the std::vector::erase function. It seems illogical that you can’t call erase on a const_iterator, because the iterator is identifying the location within the vector, not whether you have permission to modify the vector. You’re not modifying something through the iterator. In the same sense, it seems to me that if there is such a thing as a const Node* I should be able to use it to set the selection in a document as long as I have a non-const pointer to that document. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler da...@apple.com wrote: From a const Node* you can get: - a non-const pointer to a parent, sibling, or child - a non-const pointer to the document - a non-const pointer to the renderer - a non-const pointer to the style - a non-const pointer to various shadow-related ancestors and hosts That’s one problem. Extending the const-ness of the node to mean constness of everything you can get through all these pointers would be a big task, and it’s not clear it would be worthwhile. From the perspective of Node itself, I'm not sure why this would be a big task. There shouldn't be any const accessors that return non-const pointers. Simply removing the const qualifier on all the above accessors would make things correct, at the expense of possibly making it difficult to use a const Node*. Adding const versions of the accessors where necessary, which themselves vend const pointers, is not significantly harder. The only way this is a big task is if there are callers that make significant use of const pointers to do non-const actions. Then we need to clean these up. But if they're doing non-const actions, then the cleanup is simply to make them use non-const pointers. Further, from the document you can get to the frame and things like the selection controller. Similarly, you shouldn't be able to get non-const pointers to the frame or selection controller from a const document pointer. Experience with the C++ standard library taught me that a constant pointer to something within a collection is a difficult concept to model with const. The key example here is the std::vector::erase function. It seems illogical that you can’t call erase on a const_iterator, because the iterator is identifying the location within the vector, not whether you have permission to modify the vector. You’re not modifying something through the iterator. Whether or not it's reasonable to have non-const functions on containers, which modify only the container and not the elements within it, take const pointers to elements, seems like a separable question from the rest of the issues with using const correctly. I happen to find the standard library's behavior here more reasonable than what you suggest, but regardless, all of the other cases above could certainly be handled in a clearly correct fashion. In other words, I don't find this problem a compelling reason to discard the entire idea of constness when it comes to objects which participate in tree/graph relationships. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Jun 3, 2011, at 5:46 PM, Peter Kasting wrote: From the perspective of Node itself, I'm not sure why this would be a big task. There shouldn't be any const accessors that return non-const pointers. Simply removing the const qualifier on all the above accessors would make things correct, at the expense of possibly making it difficult to use a const Node*. Maybe you can give it a try and report back. I think you’ll find that this is an enormous task. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
