rename Yandex2 to be Yandexv2

[gilesc50]

following the Googlev3 naming convention,

[ChALkeR]

Is this really a good idea?

Why didn't microsoft7 get renamed?

[ChALkeR]

By the way.

It is confusing that «microsoft» is the backend for Bing Maps v6, and «microsoft7» is the backend for Bing Maps v7.
It's not clear how those two are related (judging from the name only).

Maybe it's also worth renaming «microsoft» to «microsoftv6» and «microsoft7» to «microsoftv7» while it's still possible before the release?

[gilesc50]

Now its only the Microsoft one that's wrongly named.

[ChALkeR]

The same for OpenLayers.

When there will be a backend for OpenLayers v3, it will be (presumably) named openlayersv3.

That will create confusion, because openlayers will be the backend for OpenLayers v2, and openlayersv3 will be the backend for OpenLayers v3.

The naming is still incosistent.

[ChALkeR]

That was the case why I asked if it is a good idea to force some naming convention.

My point is that:

1. It was working fine as it was. The mapping of original api names like «Yandex.Maps v3», «Google Maps v3», and «Bing Maps v6» to internal identifiers like «yandex2», «googlev3» and «microsoft» was available in the documentation.
2. The naming convention that you are forcing does not work in the generalized case. I described some examples above.

If you are saying that there is some sort of naming convention that you are following, that naming convention should be at least understandable, clean, and not broken, right?

[ajturner]

I would suggest we simplify to just the vendor or project name and drop any versions. These can be implicit in the MXN implementation.

The only reason there is a googlev3 is because of the transition and dual offering from google with v2. Lets not propagate that anymore.

[ChALkeR]

Umm, both Yandex.Maps v1 and Yandex.Maps v2 are currently working and supported APIs.
I see exactly no reasons to remove Yandex.Maps v1 support, for example.

The same for Bing Maps v6 API, if I am correct.

[ChALkeR]

Or are you proposing to merge implementation for all the versions in a single file, and perform some kind of auto-detect there? That's major versions, not minor. The API has severe differences (including design differences).

That would just double the filesize for the provider backend in most cases. Bad idea.

[vicchi]

I don't think that having a single implementation for multiple supported versions of a provider is the right thing to do. Microsoft/Bing continues to support both the v6 and v7 implementations of their API. When OpenLayers v3 comes out, it will be a considerable while before OpenLayers v2 goes away. Google v2 continued to be supported long after Google v3 was released and although v2 is now on the way out, it's not unreasonable to assume that the same will happen once v4 makes it out into the wild. And so on ...

But ... the current naming convention isn't really a naming convention at all, it's more the side effect of the organic way provider support has grown in Mapstraction.

I'm currently reworking the way in which Mapstraction handles the inclusion of the different provider implementations to allow mxn.js to automagically (pre) include the provider API includes, so if you specify mxn.js?(leaflet), this will automagically include all of Leaflet's script and style files, before including mxn.leaflet.core.js.

So, following on from this ... I can add support so that we have a sane naming convention for all the versions of the providers (googlev2, googlev3, microsoftv6, microsoftv7 and so on) but continue to support the old provider implementations as well. In effect microsoftv6 is an alias for microsoft and so on.

That way, we move to a sane naming convention, which we support going forwards, but don't break compatibility with existing code which uses these providers out in the wild.

The next version of Mapstraction will be a major version number hike, which means we can, in principle, break backwards compatibility. And, indeed, there will be some breaks, but I want to try and keep them to a minimum.

Making a consistent naming and versioning strategy for supported providers, whilst not immediately breaking all old implementations, makes sense to me and this is what I'm working on right now.

[gilesc50]

Gary that is an excellent suggestion, I was going to suggest roughly the same.

However I'd like to suggest that we rename EVERY provider file so it has the version number in it e.g. mxn.yandexv1.core.js and mxn.yandexv2.core.js and that requesting the provider yandex from the api uses the latest version. (I realise that this would change the version returned by requests for "Google" which is about to obsolete the v2 by the end of the year, "yandex" and "Microsoft", but feel this 1 time pain would be worth it now while you change the way scripts are loaded and allows us to follow Andrew's advice by hiding the version numbers and yet still allow someone to deliberately load microsoftv6 or yandexv1 if they really wanted to.

Taking this on, some providers do supply useful minor versioning too, so I would propose we have these provider files:

mxn.yandexv1.core.js
mxn.yandexv2.core.js (this would be the one returned when asking for "yandex" and be a breaking change - but a good one!)

mxn.openlayersv2.13.core.js rename the current provider and make "openlayers" return this one (if you want to just use v2 here I dont mind instead of 2.13)
mxn.openlayersv3.core.js - I am slowly working on this, but we wouldn't move "openlayers" to return this one until it is stable.

mxn.esriv3.5.core.js (callable with version number or by "esri")
So I fixed up the esri one (on a release-3-esri-fixes branch) and noticed that there were significant changes at 3.4 that should really have been versioned to a 4.0 but weren't - you cant use the new fixes with esri 3.2 that we previously implemented against - so we could also provide an esriv3.2 if we really wanted to.

mxn.leafletv0.6.core.js (callable with version number or by "leaflet")
NB calling a file just mxn.leafletv0.core.js would be weird (and 0.7 is labelled as "In-progress major version," so may need to be treated as a major version ...)

Microsoft doesn't announce the minor versions at all, they just do ninja updates.
mxn.microsoftv6.core.js
mxn.microsoftv7.core.js (this would be the one returned when asking for "microsoft" and be a breaking change - but a good one!)

Google only ever support 1 minor version back its not worth keep track of their minor versions in our provider filename - but if you felt compelled to call it googlev3.14 I wouldn't object.
mxn.googlev2.core.js
mxn.googlev3.core.js (this would be the one returned when asking for "google" and be a breaking change - but a good one! until the v2 is retired in 3 months - it even keeps catching me out and I load the Google one when I wanted the v3!)

mxn.nokiav2.core.js also return it by asking for just "nokia"
mxn.openmqv7.core.js also return it by asking for just "openmq"
mxn.mapquestv7.core.js also return it by asking for just "mapquest"
mxn.openspacev4.core.js and also return it by asking for just "openspace"
mxn.ovi.core.js does this have a version number?

PS for anyone requesting an obsolete api such as cloudmade, cartociudad or geocommons, could you please throw a "no longer supported message" from core, without us needing the obsoleted provider file in the code tree?

[vicchi]

Whoah .... I think taking the naming convention to include major, minor and patch numbers is probably taking this too far.

So far, all API providers follow the semantic naming convention, so I think we really only need to differentiate between major version revisions. Yes, there's always a chance a provider won't follow this, or another provider will come along that doesn't but so far this isn't the case so I don't want to code around what might be coming down the pipe.

I propose we (effectively) rename all the provider implementation for their major version numbers, keeping the original names (where they exist) as aliases and leave it at that, so avoid being overly complex.

As an aside, I think throwing a "no longer supported" exception from mxn.js rather than from the provider implementations is an excellent idea; I'll implement this.

[vicchi]

Quick heads up ... there will be a release-3.0-autoload branch created soon-ish, where all of the above will appear, once I've got it working enough to warrant committing to the main repository.

Once I've done these, we can haggle over how this all hangs together and whether my reading of all of this matches with everyone else's and then, providing we agree, I'll merge into the main release-3.0 branch.

Still a lot of coding and testing to be done before we get to that stage ... but isn't that always the way?