Offer to Maintain the Online DPDB Cache

[thoragio]

I've created a copy of the online DPDB cache here:
https://rawgit.com/thoragio/webvr-polyfill-dpdb/master/dpdb.json

And my repo for it is here:
https://github.com/thoragio/webvr-polyfill-dpdb

There have been a few requests to add new devices to this list over the last couple of months, so I am proposing to maintain this list at the links above. I would also continue to post PRs to your repo so that the offline cache in your repo is eventually kept up-to-date with the online one at the URL above.

If you guys are happy with this, I suggest to change the ONLINE_DPDB_URL to the rawgit.com URL above in src/dpdb/dpdb.js. Let me know and I will submit the required PR.

[thoragio]

@borismus - friendly ping to get your feedback on my offer to maintain the online DPDB cache. Thanks.

[kfarr]

+1 this is a big blocker for a-frame users; lack of proper iOS support is not good

[kfarr]

In fact, just looking through the open issues, a good chunk of issues are directly related to maintaining the DPDB:

• Samsung Galaxy S6 incorrect display parameters #129
• Edge Mobile support #139
• Galaxy S7 | iPhone 7 | DPDB : In general how to compute? #164
• Double vision on Pixel XL #176
• DPDB_CACHE has duplicate entries for ios devices (aka iPhones) #181
• Missing Smartphone #188

While @thoragio's offer may not help solve all of them, it could make a big dent immediately.

[borismus]

Sorry for the delay here. DPDB is generated from an internal database which has since gone stale. We need to work out a better story, please stay tuned.

[brianchirls]

I'd like to give this a bump and re-iterate the importance of getting this fixed.

Even though Chrome is making progress toward native Cardboard support, it's still some way off before it's supported in WebViews or Chrome Custom Tabs, which includes progressive web apps installed to home screen, not to mention Firefox, Samsung Internet, Mobile Safari, etc. And I'm seeing more and more cases of unmatched phones, which results in distortion so bad it's nearly unusable, especially as screens get bigger.

Since I can't find any documentation online of the source for this database or it being used in any other projects, I'm not opposed to forking it and either maintaining it here or in another repo.

In any case, if the online database is so unreliable, we should not be obliterating the cache when the remote database is loaded. Perhaps just append the new entries to the existing array, or insert them at the top. Maybe make it configurable.

[jbreckmckye]

Currently A-Frame maintains a fork with its own DPDB cache data. It might be worth using that instead until upstream gets fixed.

[HalfdanJ]

@toji any good ideas how this can get a better workflow? Seems like one of the main reasons for a-frames fork.

[cvan]

@HalfdanJ I'd recommend the following:

1. accept PRs to make DPDB_CACHE ensure it's as up to date as possible; it's used here, as a fallback
2. allow ONLINE_DPDB_URL to be a configurable setting, if people need newer/different projections and configurations: https://github.com/googlevr/webvr-polyfill/blob/c484e22ca9c10b279d91c736a6a33a86d3cd1e3e/src/dpdb/dpdb.js#L22
3. allow a custom setting (e.g., a DPDB_OVERRIDES method) that can manipulate (append, remove, insert, cancel, etc.) the DPDB calls.

[cvan]

Friendly ping, @toji, @HalfdanJ: what do you think of @thoragio's suggestion about maintaining the DPDB? Or any advice on other ways the DPDB can be maintained going forward?

[HalfdanJ]

I think this sounds like a good solution.

[toji]

Sounds good to me!

[thoragio]

OK. I have submitted the PR.