Maps v3 bindings status

[Eric Ayers]

I added some new comments to issue 381, "Upgrade to Maps v3"

http://code.google.com/p/gwt-google-apis/issues/detail?id=381

on the request for a maps v3 bindings. I'll paraphrase them here,
because I'd like for this discussion to continue in the group

...This issue, number 381 is a request for a new feature as far as the
gwt-google-apis library is concerned. Yes, it is something we'd like
to add, but there is no one working this new feature. Please do not
make future plans expecting it to arrive at a certain time because
there is no timeline for fixing it or the other outstanding new
feature requests.

We had a change branch going for a while (see the SVN repository under
changes/vinays), but now no one is available to work on it. That
change branch relies on the JSIO library which is much less efficient
than using JavaScriptObject overlays. We were trying to get rid of
JSIO and tease out other inefficiencies. There have been some ideas
tossed around for automatically generating an API from the
documentation, but I've only done a proof of concept - there are
complexities in mapping class hierarchies and parameters that are
closures in JS to Java constructs. Its pretty simple to look at the
design and do it by hand, but difficult to write an automatic rule
for. And even if all that were done, to be an official library, we'd
need unit tests, documentation, examples...

We are maintaining existing features of the API. It is an open source
project and if someone wants to make a contribution, let's talk about
it on the gwt-google-apis group.

There is more than one third party wrapper checked in to Google Code.
If you would like some help wrapping any JavaScript API there are many
examples you can look to on Google Code and a vibrant GWT community.
...
Let me add one more comment. Some developers might be waiting for a
gwt-google-apis official set of bindings because they hope to be able
to upgrade to v3 without changing the API.

The Maps v3 API is incompatible with the Maps v2 API and any attempt
to make new GWT bindings will likely break source and binary
compatibility as well. The v3 API was carefully crafted to be
lightweight enough for use on mobile devices, and I'd like to see any
official GWT bindings remain true to that design goal.

-----

As far as how you could contribute to a new v3 bindings. There is a
change branch in

http://code.google.com/p/gwt-google-apis/source/browse/#svn%2Fchanges%2Fvinays%2Fgwt-google-maps-v3

that was being worked on. The starting point was the
gwt-google-maps-v3 project.

http://code.google.com/p/gwt-google-maps-v3/

We have been trying to strip out the JSIO support, and to remove
features that would cause extra objects to be created. You can review
the code reviews by joining the gwlgwt-issue-notification group and
looking back a ways. There should be references to code reviews on
gwt-code-reviews.appspot.com

https://groups.google.com/forum/#!forum/galgwt-issue-notifications

For information about the contribution process, see the gwt-google-apis wiki:

http://code.google.com/p/gwt-google-apis/wiki/MakingGALGWTBetter

--
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA

[Andrew n marshall]

On this note, I've been working on a near ground up rewrite of the v3
Maps bindings using overlay objects. It is very premature, and focused
on the features I need for my own project. However, since maps are a
key point of my app, that is a lot of features.

When I get to a point that is usable and stable, even if incomplete, I
intend to contribute it back to the project. Unfortunately, being a
side project, that may not be soon.

--
Andrew n marshall
Today of Tomorrow Studios

[Eric Ayers]

Thanks for offering this up.  In the mean time, I'll be happy to offer what I can in the way of advice or code reviews.  You can put up code for review on http://gwt-code-reviews.appspot.com if you like.

--
You are subscribed to the Google Groups "GWT-Google-Apis" group.
For more options, visit http://groups.google.com/group/gwt-google-apis?hl=en

[Brandon Donnelson]

Just for clarification, focus will be on this changes branch: http://code.google.com/p/gwt-google-apis/source/browse/#svn%2Fchanges%2Fvinays%2Fgwt-google-maps-v3

And JSIO should be focused on first?

[Brandon Donnelson]

Has anybody run automatic api build before?

Wow that would be the way to do it. Does anybody have any base projects that could be used to do that, or would something like that have to be started from scratch?

[Nicolas]

(note: while you are right in saying that the mailing lists is the proper place for this discussion i hope you realize that by moving it to a place that requires a subscription, many would think that it is an inelegant but convenient way attempt to kill any further comment)

I am deeply sorry to insist in commenting this issue, but i can't help myself but express my feelings.

...This issue, number 381 is a request for a new feature as far as the
gwt-google-apis library is concerned.  Yes, it is something we'd like
to add, but there is no one working this new feature.  Please do not
make future plans expecting it to arrive at a certain time because
there is no timeline for fixing it or the other outstanding new
feature requests.

Google Maps is supposed to be a strategical part in the Google APIs suite. You cannot expect people think that tracking upstream API version it won't be high to very high priority in development goals. To me, avoid updating the API compatibility is just a synonym of letting it die. You may now understand the urge in our need to have some feedback on this API future.

I suspect that the lack of information also comes for the lack of firm decision on this issue, which is, to me, a symptom that it is more important that a simple feature request. It is important enough in way that, while having no solution to release it, you can't just close the issue and tell people that v3 will not be released. Which would have been the fate of any non-critical feature with no development plan and resource.

We had a change branch going for a while (see the SVN repository under
changes/vinays), but now no one is available to work on it.  That
change branch relies on the JSIO library which is much less efficient
than using JavaScriptObject overlays.  We were trying to get rid of
JSIO and tease out other inefficiencies.   There have been some ideas
tossed around for automatically generating an API from the
documentation, but I've only done a proof of concept - there are
complexities in mapping class hierarchies and parameters that are
closures in JS to Java constructs.  Its pretty simple to look at the
design and do it by hand, but difficult to write an automatic rule
for.  And even if all that were done, to be an official library, we'd
need unit tests, documentation, examples...

So basically the v3 integration, due to the lack of satisfying technical solution and development resource, has been dropped since this summer (latest branches changes), with absolutely no information. Maybe an update status on the issue (either pointing out an active branch or telling us that development was stale) would have been enough to help people in understanding what was happening.

We are maintaining existing features of the API.  It is an open source
project and if someone wants to make a contribution, let's talk about
it on the gwt-google-apis group.

There is more than one third party wrapper checked in to Google Code.
If you would like some help wrapping any JavaScript API there are many
examples you can look to on Google Code and a vibrant GWT community.
...

On issue #381 people has expressly  asked to have information on development process to be able to prepare themselves for the official gwt-maps-v3. Many were aware of existing third party implementations, they just did prefer wait for the official one.
On comment #3 of the issue you tell us that the API that will probably the nearest of the official version is gwt-google-maps-v3, and the gwt-google-maps-v3 home page was saying that "This project will soon be merged into gwt-google-apis and hence is depricated". Merge meant probable change for integration between the repositories, which means to all developers that 1) if they wait a little, they might avoid some trouble 2) they don't need to look to what's happening to gwt-google-maps-v3, it's dead anyway, 3) we can't test or contribute to the project since no obvious current version appears on public development trees.

Let me add one more comment.  Some developers might be waiting for a
gwt-google-apis official set of bindings because they hope to be able
to upgrade to v3 without changing the API.

That's a very wise assumption. I personally did not wait for a 100% compatible API (and my code uses a lot of workaround that are highly dependent on v2 behavior, so I was pretty sure to be out of luck here). But I also suspect that many did not wait a 100% compatible API. Which make them even more eager in having at least an idea of what kind of changes they should wait for, and start thinking about solutions ASAP, even if might not have been final ones due to probable changes on either side.

But just because some would like a 100% compatible API does not meant that the others should be deprived of information, and also, preventing a v3 version because it would not be API compatible seem to bring more trouble that releasing an incompatible version. Maybe it brings less discussion, but silent users are not necessarily happier users.

The Maps v3 API is incompatible with the Maps v2 API and any attempt
to make new GWT bindings will likely break source and binary
compatibility as well.  The v3 API was carefully crafted to be
lightweight enough for use on mobile devices, and I'd like to see any
official GWT bindings remain true to that design goal.

I've been aware of this for almost one year. This is exactly why people is asking information about development status. Yet, it is only now that i can get any.

As far as how you could contribute to a new v3 bindings.   There is a
change branch in

http://code.google.com/p/gwt-google-apis/source/browse/#svn%2Fchanges%2Fvinays%2Fgwt-google-maps-v3

that was being worked on.  The starting point was the
gwt-google-maps-v3 project.

  http://code.google.com/p/gwt-google-maps-v3/

We have been trying to strip out the JSIO support, and to remove
features that would cause extra objects to be created.  You can review
the code reviews by joining the gwlgwt-issue-notification group and
looking back a ways.  There should be references to code reviews on
gwt-code-reviews.appspot.com

I can't help myself but notice that the mention of the merging has disappeared from gwt-google-maps-v3. Since when, i don't now.
This mention has de facto bring down any interest on the project. The merge has been done, with no information to the users that expressly wanted to see what could be the final shape of the API. (note the italics). And give them the opportunity to contribute back or comment. With no information, a dead branch just look like a dead branch, not a good basis for any work. And now, after months lost, you tell us that it is, actually, the only piece of code we can wait for.

I understand the uncertainty of software development, the very high expectations from your users (which is quite legitimate since google brags a lot about its ability to hire top notch engineers), the difficulties in deciding where to put the priorities and, i suspect it is the problem here, getting the motivation in bothering with less interesting problems. But whatever happens, whatever are your feelings, you can't expect people that depends on information, or in this case, lack of, being satified with a status quo.

I hope that you are realizing how much frustration and i think, anger, this issue has raised, the sudden burst of today comments on the issue seem edifying to me.

[Eric Ayers]

I think that would be a good focus. The automatic API generation I
was pursuing uses a non-public artifcact of the Maps API build
process. In theory, it could be done by parsing the HTML in the Maps
JavaScript API Reference.

> --
> You are subscribed to the Google Groups "GWT-Google-Apis" group.
> For more options, visit http://groups.google.com/group/gwt-google-apis?hl=en

--

[Brandon Donnelson]

Wow. I can see the the challenge, yet the automating reward could be worth it. 

Whats the next step? Can you write down the items that need to be figured out, so people can grab onto them and help. Bite size chunk list, to delegate some of the items you could use the help on.  

Then hand writing unit testing, docs and samples wouldn't be so bad. 

Brandon Donnelson

http://gwt-examples.googlecode.com

[Andrew n marshall]

Yes.  That is my reference code base.  I've started there, with the guts ripped out, as a skeletal structure for the rewrite.  There is no JSIO in my codebase.  As I encounter classes that were written with JSIO, I am rewriting them.  It extremely early in the project, it's a mess at the moment, and nothing works.

Once I have some simple examples working, make a git repo for code review and people can comment then.

I'm learning GWT as I go for the larger project.  And I have a little more to do before I start really focusing on the map components, but that is coming soon as long as I can keep my spare time free.

--
Andrew n marshall
Today of Tomorrow Studios

On 2/24/11 9:23 AM, Brandon Donnelson wrote:

Just for clarification, focus will be on this changes branch:  http://code.google.com/p/gwt-google-apis/source/browse/#svn%2Fchanges%2Fvinays%2Fgwt-google-maps-v3

And JSIO should be focused on first?

[Brandon Donnelson]

I started an issue to gain support for automating the javascript implantation builds.

http://code.google.com/p/gwt-google-apis/issues/detail?id=452 - automating javascript implementation builds for gwt apis

Brandon Donnelson

http://gwt-examples.googelcode.com

[Buzzterrier]

I used the GWT Maps API some years ago. I loved the tight GWT integration, but was disappointed that it was not as feature complete as the Google Maps API. Presently I have a new opportunity to do another map based project, and I am again disappointed and concerned that the GWT Maps API is still lagging behind. It appears to me that GWT is a second rate citizen in the Google empire, which is not surprising with the battle being waged in the mobile arena.

[John Malpas]

My organization has made a few web applications
with GWT and the official Maps V2 library.
We also have made mobile/HTML5 apps with GWT,
but not yet with Maps.

I just went to a Google Earth Outreach program where the
presenters emphasized that the Maps V2 API was deprecated,
and that we all (developers in the audience) should switch
to Maps v3. After hearing that, I am hesitant to put much more effort
into GWT + Maps V2, much as I like it.

Over the past two days I have tried using this:
http://code.google.com/p/gwt-google-maps-v3/
in a new application. I did get it to work, but had
to stop when I came up against the lack of support for
(what were called in V2) TileOverlays. Our map
applications rely on a custom tile layer which appears
on top of the Google Map Type

Here is a concrete question: I am wondering if it
is worthwhile to keep going with
http://code.google.com/p/gwt-google-maps-v3/
and try to add the needed tile overlays with
JNDI and ImageMapType. Either that or,
again with JNDI, try to add a V3 KMLLayer
that duplicates the effect of the custom tile layer.
Other than that, at the moment I do not see a
migration path from Maps V2 to Maps V3
for our GWT applications.

Any advice appreciated.
(Another thing they said at the Google Outreach program
was this: use Google Groups to say what features
you want.)

[Brandon Donnelson]

Eric and/or Piotr, I think you have the most experience with the API build process. I'd really like to help with the v3 bindings/implementation/api for maps v3, but I wouldn't know where to start. I'm assuming your tasked with other priorities, but could you head up a process to approach the code rewrite in smaller tasks for us outside folks to help? Would it be able to start a wiki to direct the acquisition of code patches.

I'd suggest putting a road map on your site, so others can see the scope of what you do. I'm curious to the future of google apis? How are you going to keep up with future versions of the javascript apis? How is management looking on GWT future? I would write about this on your site. Maybe budget and manpower has something to do with it, either way, it would be nice to know more about the future on your site of the Google Apis. 

I really believe that GWT apis is becoming more important and the more apis we have, the easier, faster, and better we can concentrate on building great applications quicker than our competitors, which I would think benefits Google in the long run. 

What is the roadmap for the Google Apis? 

Thanks for working on this.

Brandon Donnelson

http://gwt-examples.googlecode.com

[Brandon Donnelson]

Could you get the javascript guys to spec out there javascript libs docs in xml, to help with auto building?

[Jerry F]

How about Google slashes one quarter's profit by .01% and spends a lousy quarter million on

addressing this issue?

I built an application in good faith on GWT + Maps API, and

I am now hearing complaints from a smartphone user that he

sees "this site uses deprecated old garbage from some pterosaur company

called Google that's too trendy and busy brewing lattes to care about

their own last week's technology"

I'm sorry for the rag, Eric, I understand that you're trying, but others stripping out

as useless several comments from other developers saying they need some progrefs on this

issue, and thus making the demand look smaller, is twisted.

Yes, if I were a god, I could roll my own, if I were a demigod, I could help Malpas push the

rock up the hill, but no, I used GWT+MAPS because it was quick and easy and I could do

something nice in my spare time, and now that is going to piss away because Google can't

support its own technology.

[Brandon Donnelson]

Would you suggest rewriting the current source of v3 impl, or starting over for new source for v3?

[Brandon Donnelson]

Never mind, you've updated quite a bit. Good job.