Hi folks, Wondering whether I can get a quick show of hands from those of you who use OpenLayers. The latest version of the API has some refinements for adding the OSM layers which it would be good to take advantage of. If anyone who uses OpenLayers is planning to upgrade from Mapstraction v1 to v2 would it be acceptable to have to upgrade OpenLayers too? That''s assuming you don''t just point at the latest script all the time. I think there may be an additional point here about us needing to be specific about which versions of the provider APIs a particular version of Mapstraction is supposed to work with. I think most of the providers have an API version property which we could check but at the very least I think we need to document it on the site and in the code as well. Anyone got any thoughts on this? On an unrelated note I''m wondering what people think of going with TERRAIN for the new map type rather than PHYSICAL, I think TERRAIN makes more sense personally. Derek -- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100522/951b3f8f/attachment.htm>
On May 21, 2010, at 4:02 PM, Derek Fowler wrote:> I think there may be an additional point here about us needing to be specific about which versions of the provider APIs a particular version of Mapstraction is supposed to work with. I think most of the providers have an API version property which we could check but at the very least I think we need to document it on the site and in the code as well. Anyone got any thoughts on this?Agreed. And this could solve the Google V2/V3 issue as well.> > On an unrelated note I''m wondering what people think of going with TERRAIN for the new map type rather than PHYSICAL, I think TERRAIN makes more sense personally.TERRAIN does make more sense. Google''s actually inconsistent on this point, as the constant for the map type in their API is G_PHYSICAL_MAP, yet the label visible on the map says TERRAIN. Lev Tsypin _____________________ Level Online Strategy, LLC 503.342.8044 levelos.com | twitter.com/levelos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100522/fcb25226/attachment.htm>
agree with Lev in both questions:
- v2/v3 naming system would be a good and simple option
- Terrain is more legilble than physical
regards
--
Saludos,
Pablo L?pez Escob?s
2010/5/22 Lev Tsypin <lev at levelos.com>
>
> On May 21, 2010, at 4:02 PM, Derek Fowler wrote:
>
> I think there may be an additional point here about us needing to be
> specific about which versions of the provider APIs a particular version of
> Mapstraction is supposed to work with. I think most of the providers have
an
> API version property which we could check but at the very least I think we
> need to document it on the site and in the code as well. Anyone got any
> thoughts on this?
>
> Agreed. And this could solve the Google V2/V3 issue as well.
>
>
> On an unrelated note I''m wondering what people think of going with
TERRAIN
> for the new map type rather than PHYSICAL, I think TERRAIN makes more sense
> personally.
>
> TERRAIN does make more sense. Google''s actually inconsistent on
this point,
> as the constant for the map type in their API is G_PHYSICAL_MAP, yet the
> label visible on the map says TERRAIN.
>
> Lev Tsypin
> _____________________
> Level Online Strategy, LLC
> 503.342.8044
> levelos.com | twitter.com/levelos
>
>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100523/7a6aa0d4/attachment.htm>
I like TERRAIN also. It looks like some of the mxn.*.core.js scripts do a test or two in init() to see if the proper API is loaded, and raise an alert() if not. It seems like version or capability tests on the provider API could be performed there too. Would throw() be better than alert() if tests fail, since the problem will probably have to be addressed by a developer? -dylan- 2010/5/23 Pablo L?pez Escob?s <plopesc at gmail.com>> agree with Lev in both questions: > > - v2/v3 naming system would be a good and simple option > - Terrain is more legilble than physical > > regards > > -- > Saludos, > Pablo L?pez Escob?s > > 2010/5/22 Lev Tsypin <lev at levelos.com> > >> >> On May 21, 2010, at 4:02 PM, Derek Fowler wrote: >> >> I think there may be an additional point here about us needing to be >> specific about which versions of the provider APIs a particular version of >> Mapstraction is supposed to work with. I think most of the providers have an >> API version property which we could check but at the very least I think we >> need to document it on the site and in the code as well. Anyone got any >> thoughts on this? >> >> Agreed. And this could solve the Google V2/V3 issue as well. >> >> >> On an unrelated note I''m wondering what people think of going with TERRAIN >> for the new map type rather than PHYSICAL, I think TERRAIN makes more sense >> personally. >> >> TERRAIN does make more sense. Google''s actually inconsistent on this >> point, as the constant for the map type in their API is G_PHYSICAL_MAP, yet >> the label visible on the map says TERRAIN. >> >> Lev Tsypin >> _____________________ >> Level Online Strategy, LLC >> 503.342.8044 >> levelos.com | twitter.com/levelos >> >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100523/31209fd5/attachment.htm>
They do however I''m concerned less with whether an API is loaded or not and more with documenting which versions of a provider API Mapstraction is known to work with. That was we can ship a compatibility readme file with each release stating which API version it targets. Note that I''m not talking about to Google v2 & v3 issue as they are totally different APIs. I''m talking about minor version changes where new features are added but the API as a whole remains the same. I''ll have to have a look for those alerts and either change them to throws or remove them. I changed a few in a recent commit to SVN but I want to take them all out. Derek On May 23, 2010 4:05 PM, "Dylan Kuhn" <dylan.k.kuhn at gmail.com> wrote: I like TERRAIN also. It looks like some of the mxn.*.core.js scripts do a test or two in init() to see if the proper API is loaded, and raise an alert() if not. It seems like version or capability tests on the provider API could be performed there too. Would throw() be better than alert() if tests fail, since the problem will probably have to be addressed by a developer? -dylan- 2010/5/23 Pablo L?pez Escob?s <plopesc at gmail.com>> > agree with Lev in both questions: > v2/v3 naming system would be a goodand simple option > Te... _______________________________________________ Mapstraction mailing list Mapstraction at lists.mapstraction.com http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100523/85f05bda/attachment.htm>
In these cases, I think that the best option is wrap provider scripts into classes and overwrite only that methods that differs from one version to anotherfor example: var newVersion = new providerXXXX();> newVersion.prototype.methodToOverwrite = function(){....} > > mxn.register(''APIName'', newVersion) >What do you think?? -- Saludos, Pablo L?pez Escob?s 2010/5/23 Derek Fowler <dezfowler at gmail.com>> They do however I''m concerned less with whether an API is loaded or not and > more with documenting which versions of a provider API Mapstraction is known > to work with. That was we can ship a compatibility readme file with each > release stating which API version it targets. > > Note that I''m not talking about to Google v2 & v3 issue as they are totally > different APIs. I''m talking about minor version changes where new features > are added but the API as a whole remains the same. > > I''ll have to have a look for those alerts and either change them to throws > or remove them. I changed a few in a recent commit to SVN but I want to take > them all out. > > Derek > > On May 23, 2010 4:05 PM, "Dylan Kuhn" <dylan.k.kuhn at gmail.com> wrote: > > I like TERRAIN also. > > It looks like some of the mxn.*.core.js scripts do a test or two in init() > to see if the proper API is loaded, and raise an alert() if not. It seems > like version or capability tests on the provider API could be performed > there too. Would throw() be better than alert() if tests fail, since the > problem will probably have to be addressed by a developer? > > -dylan- > > 2010/5/23 Pablo L?pez Escob?s <plopesc at gmail.com> > > > > agree with Lev in both questions: > v2/v3 naming system would be a > good and simple option > Te... > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100523/cd946b61/attachment-0001.htm>
I''d think be happy enough to see the provider API versions that a Mapstraction release was tested with in the release notes, which I would expect to be the current versions at the time of the release. -dylan- On Sun, May 23, 2010 at 10:15 AM, Derek Fowler <dezfowler at gmail.com> wrote:> They do however I''m concerned less with whether an API is loaded or not and > more with documenting which versions of a provider API Mapstraction is known > to work with. That was we can ship a compatibility readme file with each > release stating which API version it targets. > > Note that I''m not talking about to Google v2 & v3 issue as they are totally > different APIs. I''m talking about minor version changes where new features > are added but the API as a whole remains the same. > > I''ll have to have a look for those alerts and either change them to throws > or remove them. I changed a few in a recent commit to SVN but I want to take > them all out. > > Derek > > On May 23, 2010 4:05 PM, "Dylan Kuhn" <dylan.k.kuhn at gmail.com> wrote: > > I like TERRAIN also. > > It looks like some of the mxn.*.core.js scripts do a test or two in init() > to see if the proper API is loaded, and raise an alert() if not. It seems > like version or capability tests on the provider API could be performed > there too. Would throw() be better than alert() if tests fail, since the > problem will probably have to be addressed by a developer? > > -dylan- > > 2010/5/23 Pablo L?pez Escob?s <plopesc at gmail.com> > > > > agree with Lev in both questions: > v2/v3 naming system would be a > good and simple option > Te... > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100523/d3dc3ca4/attachment.htm>
This would mean we''d bloat the library with a lot of backwards compatibility code. It''s reasonable to expect that if a user is upgrading their version of Mapstraction that they would be happy to upgrade the version of the underlying API they''re using. Mapstraction insulates them from changes in the provider API so this should be quite low friction so long as they aren''t directly using some of the underlying APIs features, which may have changed. Derek 2010/5/23 Pablo L?pez Escob?s <plopesc at gmail.com>> In these cases, I think that the best option is wrap provider scripts into > classes and overwrite only that methods that differs from one version to > anotherfor example: > > var newVersion = new providerXXXX(); >> newVersion.prototype.methodToOverwrite = function(){....} >> >> mxn.register(''APIName'', newVersion) >> > > What do you think?? > > -- > Saludos, > Pablo L?pez Escob?s > > > 2010/5/23 Derek Fowler <dezfowler at gmail.com> > > They do however I''m concerned less with whether an API is loaded or not and >> more with documenting which versions of a provider API Mapstraction is known >> to work with. That was we can ship a compatibility readme file with each >> release stating which API version it targets. >> >> Note that I''m not talking about to Google v2 & v3 issue as they are >> totally different APIs. I''m talking about minor version changes where new >> features are added but the API as a whole remains the same. >> >> I''ll have to have a look for those alerts and either change them to throws >> or remove them. I changed a few in a recent commit to SVN but I want to take >> them all out. >> >> Derek >> >> On May 23, 2010 4:05 PM, "Dylan Kuhn" <dylan.k.kuhn at gmail.com> wrote: >> >> I like TERRAIN also. >> >> It looks like some of the mxn.*.core.js scripts do a test or two in init() >> to see if the proper API is loaded, and raise an alert() if not. It seems >> like version or capability tests on the provider API could be performed >> there too. Would throw() be better than alert() if tests fail, since the >> problem will probably have to be addressed by a developer? >> >> -dylan- >> >> 2010/5/23 Pablo L?pez Escob?s <plopesc at gmail.com> >> >> > > agree with Lev in both questions: > v2/v3 naming system would be a >> good and simple option > Te... >> >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100523/1ac0e800/attachment.htm>