00:07
<roc>
annevk, wanderview: we're doing SQL now? why?
00:07
<roc>
Jonas is quite right, by the way. If you don't spec the same query planner then you have algorithms with different orders of complexity on different browsers, which is intolerable.
00:07
<roc>
IndexedDB doesn't have that problem
00:09
<roc>
maybe the spec doesn't say what the complexity should be, but it's pretty clear lookup should be O(1) or O(log N), and iteration the same per item, amortized. The difference between O(1) and O(log N) is not significant in practice. O(1) vs O(N) vs O(N^2) very much is
00:17
<jgraham>
Is the some repository I'm not subscribed to, or something?
00:17
<sicking>
roc: i'm also wondering where this discussion is happening
00:20
<annevk>
Just an idea, but the fact that developers write new SQL code against WebKit/Chromium is a problem
00:20
<sicking>
roc: and you are correct that the IDB spec designers all assumed that reading/writing would be O(log N) and iteration would be O(1)
00:21
<sicking>
I think count() is the only function which I'm uncertain about the complexity for
00:22
<jgraham>
What's the argument against putting the same effort into optimising https://github.com/google/lovefield ?
00:22
<sicking>
annevk: if we get to the point that we'll have to ship websql, the only realistic option is to just embed sqlite
00:22
<sicking>
annevk: writing a spec is effectively a waste of time
00:23
<sicking>
and then cross our fingers that sufficiently backwards compatible versions of sqlite will continue to be maintained forever
00:25
<sicking>
i guess another implementation strategy would be to run sqlite through emscripten
00:29
<jgraham>
Right, but if you can do that, why ship it with browsers?
00:31
<jgraham>
An interesting exercise might be to work out what would stop sqlite-though-emscripten happening today, and plug those gaps
00:31
<jgraham>
if any
00:32
<sicking>
you'd need something like the filesystem API
00:32
<sicking>
since you need the ability to do in-place modification of files
00:33
<annevk>
Perhaps if we add fulltext search to IDB we can sway some folks
00:33
<sicking>
you might also need a locking primitive, though you can do that with a shared worker
00:46
<roc>
you could use indexedDB as a block-based storage backend.
00:46
<sicking>
roc: yeah, but i suspect you'd have performance problems
00:46
<roc>
SQLite over IndexedDB over SQLite would be a bit crazy, but whatever
00:47
<roc>
sicking: it wouldn't be optimal, but if you want optimal, you don't use SQL anyway
00:48
<sicking>
roc: perf would need to be tested for sure. But I think using IDB as block storage might be problematic
00:48
<roc>
if WebSQL is or becomes necessary for meaningful Web compat, then that would suck, but I guess we'd have to spec it. I think that's the only reason to.
00:48
<sicking>
indeed
00:49
<sicking>
though i'd argue that even then writing a spec isn't worth it. Or rather, I think the spec should just be "be reasonably compatible with SQLite"
00:49
<sicking>
since i doubt that we'd write a sql engine compatible with a spec. We'd just ship sqlite
00:52
<Guest38441>
hi
00:53
<Guest38441>
Could I suggest an new function for the canvas handling here? Or is it better to do it on the mailing list?
01:11
<John2016>
Hi! I just was logged in as Guest38441. After logging out some minutes ago I looked at the logbot at http://logs.glob.uno/?c=freenode%23whatwg&s=today
01:11
<John2016>
and it simply doesn't show the text I posted here.
01:12
<John2016>
Could anyone who was online like 15 minutes ago tell me if my question showed up at all?
01:13
<John2016>
I just post my question again: Could I suggest an new function for the canvas handling here? Or is it better to do it on the mailing list?
01:13
<John2016>
Maybe someone could post it on the mailing list for me, please? :) I'm not good in using mailing lists.
01:13
<John2016>
When drawing a text on a canvas, a so far open path or subpath is closed and that way discarded. Could there be a function implemented like putTextPath?
01:13
<John2016>
So I can use the textpath in a row with other subpaths.
01:13
<John2016>
Annex: I wouldn't wonder that would be much slower for just drawing a single text, but for that the current functions would still be implemented.
01:13
<John2016>
2. Annex: I'm very sure, the current textdrawing functions are using paths themselves, as there is a high rated answer on stackoverflow on how to make a textdrawing animation, and the answer shows that using .setLineDash does that trick.
01:13
<John2016>
http://stackoverflow.com/questions/29911143/how-can-i-animate-the-drawing-of-text-on-a-web-page
01:13
<John2016>
Feel free to send me a link to an appropriate mailing list for suggesting a new function for the canvas handling, please! Thank you!
01:13
<John2016>
My Email is: John.rwhwh⊙sd
01:40
zcorpan
emailed John2016
01:54
<annevk>
🙌
03:54
<rbyers>
annevk, Domenic: sorry for delay (was on a flight to Sydney). We're still pushing ahead with shipping DOMHighRes timestamp - I'm told the angular breakage appears tolerable. https://www.chromestatus.com/features/5523910145605632
03:56
<rbyers>
But it may still fail. If it does, yes we should just add a new property.
09:06
<Domenic>
rbyers: oh cool, that's much better than I hoped. And it's in 49 which should be seeing some pretty widespread usage. Good to hear.
15:37
<annevk>
That is great to hear