Blob / Tom,
Thanks for the feedback, the statement about Premier being a future option indeed means intention, provided it provides the functionality required!!! We have EVERY INTENTION of paying for this data (as we will be for GAE, Search, Checkout, and no-doubt other services going forward). I appreciate the restriction of the Yahoo T&C's, that said if you followed the letter of their T&C's then you'd never be able to us it for anything: ;-) f. YOU SHALL NOT:(ix) use the stand-alone geocoder for any use other than displaying Yahoo! Maps or displaying points on Yahoo! Maps; (x) publish or display, or allow other users to publish or display, any geocoded location information using any Yahoo! Maps APIs; So that's helpful (I know what they are trying to say, but the literal interpretation?). My point was that in a DEV environment, why make life difficult? The GAE model makes far more sense.... Build EXACTLY what you want, test it fully, roll it out to beta users, then when you know it works (& there can be an income being generated), pay Google a little, lots, or copious amounts, of money dependant on your applications success. Why not implement a similar model in Maps with the User ID/signed request (I realise this is a question for Google), where you get X requests free, then pay X/request once the free limit is used up! No code changes, no use V2 in dev - V3 in production (if on your own server) until free requests are used up, or premier if on a shared infrastructure, etc... It's not 100% about the $$$$, just making life easy to move from POC->DEV->TEST->LIVE (Beta)->PRODUCTION without code changes to underlying calls to key Google services (in this case JUST Maps - everything else we need works that way). >From Google's POV, using Maps premier via GAE makes them money twice, the cycles for GAE + the Premier access to maps. So you'd have thought that they'd be happy to make this happen (It can't be only us doing this, can it.....?). I'm starting to think that the best way would be to get the client app to do the rev-geo invisibly in the background, and send the data back to us in an encrypted form - hey it might break our security model to some degree, but what the hell it costs us nothing, reduces our spend on GAE & Maps, Google looses revenue, it'll cost them more in bandwidth, but at-least we'll be following their strategy. All we're trying to do is ensure data quality, particularly where certain information is likely index by search engines (e.g. Google!). (Hell, we could even send it back to servers back at the office to proxy the request!) But fudge is a foodstuff, not a development strategy (not for us anyhow)! I find in even more irritating that NOBODY from Google has felt it appropriate to join in this discussion! Then again, I've had a couple of Jack & Cokes by this time, and I'm probably just ranting/venting - I'm sure my therapist will be very happy ;-) Does that make it my $0.04 worth? Dave (Apologies for rating will be forthcoming at around 7am ;-) ) -- You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group. To post to this group, send email to google-maps-js-api...@googlegroups.com. To unsubscribe from this group, send email to google-maps-js-api-v3+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.
