"Realtime being fundamentally integrated with an app or website" comes with the assumption that the visitor is always connected. This might not always be true especially for the mobile user. Users would appreciate a functional site that works well despite the intermittent connectivity than one that shows a spinning loader.
2. I'm running some realtime benchmarks on a number of hosted service providers. If I can get the geolocation it let's me add that to the benchmark results. Granted, a banner that provides info on that would be better than the bog-standard browser prompt.
3. Yeah, sorry about that. I'm interested to see where I'm sending traffic to so am capturing outbound clicks. It seems there's a bug on Chromium on Linux where the `event.metaKey` isn't set to `true` when it should be. See https://code.google.com/p/chromium/issues/detail?id=95874
13 comments
[ 2.8 ms ] story [ 46.6 ms ] threadDidn't hang around long enough to read it after that..
You can of course use that in conjunction with realtime web technologies: For example, see: http://leggetter.github.io/100-lines-or-less-js/realtime-col...
Actually, that one doesn't use the geolocation API. It's just a realtime mapping example.
This one uses the geolocation API: https://github.com/leggetter/realtime-visitor-tracker
It's actually a really good use case, but not the only one.
2. I'm running some realtime benchmarks on a number of hosted service providers. If I can get the geolocation it let's me add that to the benchmark results. Granted, a banner that provides info on that would be better than the bog-standard browser prompt.
3. Yeah, sorry about that. I'm interested to see where I'm sending traffic to so am capturing outbound clicks. It seems there's a bug on Chromium on Linux where the `event.metaKey` isn't set to `true` when it should be. See https://code.google.com/p/chromium/issues/detail?id=95874