Re: Overuse of "AssumedStale" Issue Tag

On Monday, May 27, 2013 2:25:28 AM UTC+2, V.B. wrote:

3) How much weight does the Steering Committee give to heavily starred issues (i.e. the kind that are too large for individuals to tackle)? The top three open issues are:
java.util.Calendar emulation (483 stars)

As said on the issue, there's no plan to emulate java.util.Calendar because it cannot be emulated "well enough".

We're waiting for JSR310 in Java 8, which should (a priori) be better fit. I'm concerned that all the JodaTime ports are now dead and buried though, which makes me wonder how much people rely on date/time in client code…

Comment 66 is still relevant: https://code.google.com/p/google-web-toolkit/issues/detail?id=603#c66

WebSockets for RequestFactory (218 stars)

Note that the request is about server-push. I believe Google uses their own "channel API" which is not open-source (part of it is in Closure Library), so they're unlikely to contribute the code here. Others have used GWT-Atmosphere, SocketIO or plain WebSocket (Apache Wave use the latter two).

The problems are:

• make it work in DevMode (there was an attempt to update DevMode to Jetty 7 which supports WebSockets, but it had to be abandonned because of classloader issues IIRC)
• make it work cross-browser with fallbacks (à la SocketIO or GWT-Atmostphere, but then, well, there's SocketIO and GWT-Atmostphere already, so why not just use one of them?)
• layer a high-level protocol on top of it (and BobV proposed using RequestFactory, which is why this issue is now labeled "websockets for RF", because it's "symmetric" he says –at least the client and server both know how to parse requests *and* responses, contrary to GWT-RPC– but I have a hard-time finding how that would play with the ValidationTool, locators, service locators, etc. should all these things be used on client-side? should it be restricted to ValueProxies with no locators? what would the API look like?). Many people have many different needs; some will want something "RPC-style", others more like an Event Bus just passing messages (but then there's Errai already, so why not just use it?)
• and on the server-side, server-push is useless without some sort of event bus (you don't want to use a static map/list of connected clients, that wouldn't work in a cloud environment), and all deployment targets have different capabilities so there would be a need for an abstraction there too (does that exist already? it's not specific to GWT so there's no reason anyone would have give it a go already).

 

GWT-compatible Protocol Buffer Compiler (164 stars) <-- start with this one!

What do those people want actually? A way to turn .proto files into "something" usable in GWT? Possibly with support for services? Should the server-side implementation of those services use protobuf-java-generated classes?

Or do they rather want an emulation of protobuf-java so code can be shared between the client and server? (how about services then?)

Are all those people really interested in this or are all those starts more about "protobuf looks cool, and it's made by Google which builds cool things that scale, so protobuf must be great for me, let's just see what happens there"?

Now that Square released protoparser, I'd like to revive my protobuf-gwt project, but I have to find some time first (and it requires a major rewrite of the existing code), and there haven't been much traction in the past years (are people rather using protostuff or some other lib? or are they following Wave's approach of using reflection on classes generated by protobuf-java to generate other GWT-specific things?)

For the latter two issues above, also note that our goal is to modularize GWT and externalize things (make GWT smaller, but then easier to maintain), so new features that can be built on top of GWT (rather than needing changes into GWT proper) are unlikely to be added "to GWT", but rather be created as companion projects (just like gwt-mockito and gwt-eventbinder, recently released by Google). So it's unlikely that those 2 issues will ever be fixed "in GWT proper".

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.