DefaultFileSource has responsibility for handling mapbox:// URLs

[jfirebaugh]

This moves Map::setAccessToken to DefaultFileSource::setAccessToken and passes mapbox:// URLs through the FileSource interface. No change to the iOS or Android SDK public API. The node bindings will need the following changes (cc @mikemorris):

• New values for kind enum.
• FileSource implementations need to handle mapbox:// URLs.
• Remove setAccessToken from Map interface. node-mapbox-gl-native itself no longer needs to concern itself with access tokens. This is a task for FileSource implementations now.

Before merging this I'm planning to make another change to the interface, removing the kind enum in favor of specific FileSource methods like requestStyle, requestTile, etc.

[tmpsantos]

Nice!

[1ec5]

At a glance, it looks like this will fix #1334 as well. 👍

[mikemorris]

Liking the direction here 👍

Thinking that breaking out separate requestTile, requestStyle methods could be unnecessary overhead though.

[1ec5]

I also like that the access token is no longer part of the style URL, so if the access token changes at some point during the lifetime of the file source, we don’t have to go updating other fields. This turns out to jive nicely with the last bit of refactoring I’m doing for #1553, where I’m also removing accessToken from MGLMapView.

[1ec5]

With #1553, MGLMapView no longer calls getAccessToken() anywhere.

[jfirebaugh]

@1ec5 Thanks -- I'll rebase this on master (post #1553) and redo the iOS portions.

[ljbade]

Looks good on Android side

[kkaefer]

Before merging this I'm planning to make another change to the interface, removing the kind enum in favor of specific FileSource methods like requestStyle, requestTile, etc.

We can revisit this in another pull request. Any particular reason for doing so? We don't actually use these enums anywhere (except as a hint for compressing responses), so we could do away with them as well?

[jfirebaugh]

We can revisit this in another pull request. Any particular reason for doing so?

I would like to avoid interface churn for node-mbgl or whatever the downstream consumer that implements the FileSource interface in node is nowadays. Maybe we can avoid updating it until the FileSource interface is finalized?

[mikemorris]

Working on implementing this, and I think we'll need to add some capacity to pass an access token through a Map::RenderStill call through to the mbgl::Request objects created by the FileSource implementation. Explicitly setting a global access token is going to cause race conditions when multiple maps use the same FileSource.

^ This concern will eventually be irrelevant, as the pluggable FileSource backend won't need to handle access tokens and will load resources directly.

[mikemorris]

removing the kind enum in favor of specific FileSource methods

-> #3374