who discusses the next features and adopts feature requests?

[Zied Hamdi OneView]

Hi,

I had the experience of wanting to contribute to GWT with a new feature, but I received kind of a rigid answer: "we won't adopt that, it was designed otherwise".

So I'm wondering "who decides on the design", since this if decisions are rigid there is a risk that the community will fork GWT and have different variants (which is naturally bad in essence because the energy will be split on the different projects). I think this is an important questions to solve: "who decides on priorities?"

For my concrete example: there's no "standard" solution for authorizations in GWT, addressing the problem is definitely a subject that interests the whole community. I proposed a "draft" solution that is born dead. So 

• where can we discuss the design of a solution to be adopted? 
• do we really have to wait until there are thousands of favorites on a bug to start thinking about it
  
• other platforms adopted solutions for (logging, aop, security, code organisation, ect...) if something exists and works on other platforms, isn't that an additional indicator that the feature is valuable and that it should be addressed in GWT too?

Your comments are welcome :)

[Daniel Kurka]

Hi Zied,

thanks for bringing this up. I think the right place to start discussions about any GWT feature is gwt-contrib.

In the past a lot of new features have been added to the GWT SDK in a very short amount of time. This leaves all the contributors with a huge maintenance burden and limits the amount of future work we can do, this is why we started to push back on many changes.

The best way of getting a feature into the GWT SDK these days is to evolve it as a separate open source project and when it is successful and stable we can move it into the SDK. A good example of this practice is Julien's work on the GssResource that we want to add to GWT in the future.

Do not get me wrong: We are always looking for help with many different things in GWT and maybe a good way to get started and get the sense of how we develop is to pick some small bugs from the issue tracker and propose a patch (Just +cc me on the review).

-Daniel

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ba191aeb-9c88-4fcb-a1a3-dae0d2963ac0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Google Germany GmbH

Dienerstr. 12
80331 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

[Zied Hamdi OneView]

Hi Daniel,

Thanks for your clear answer. 

From what I understood, profiles are somehow validated through they contributions quality, and that gives a weight to their opinions if they propose new ideas?. Maybe it's not a formal model but it's probably the way it works.

This seams quite wise, I'd only add into consideration the fact that (in my opinion) the majority of contributions come from a concrete need for their project, after solving the problem in the core technology, the person wants the patch to become public so he/she can profit from upgrades without having to maintain their patch to it (usually the company agrees with the decision to share the code for that reason).

So only a small part of the users will contribute, and if their propositions are rejected too fast, you won't be able to evaluate the quality of the contribution because the person won't come back before another bug. That's why I think there should be a kind of "idea hunter" mechanism (that could be driven by the community itself, without the need for Google to allocate resources for that). People could send their patches to a "parallel version" where the community could vote for a feature to become part of the core. This would raise an indicator that the feature is wanted and trigger a reflection on how to design the solution.

I'm only sharing ideas live, kind of brainstorming, there might be illogical things in what I'm proposing, but I think the subject is worth it.

p.s: I think the strength of Google was in its recruitment strategy, that made it grow without loosing efficiency. A kind of similar solution is needed for GWT as an independent open source in my opinion...

[Goktug Gokdogan]

I looked at the issue tracker.

To give you some background; UiBinder code base is quite complex, has so many features that it is really hard to maintain. And usually touching one place can easily break other places, so we usually try to prevent it to grow organically by all different request flowing on us.

On the other side, in the issue tracker you were basically asking about exposing a method from a class that is not even a public API in the first place, which basically means "please start maintaining the API of some internal implementation detail for my use case". The quick answer for that, given the state of UiBinder, is 'no'; that is basically I think where Thomas is coming from.

On the other hand, you can just start a thread in one of the discussion groups, ask and brainstorm different extensibility options, evolve the idea and propose a change in gwt-contributor group. That's probably the best way to achieve your goal and sound reasonable to me.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/71448d97-e71e-4a77-8e4d-af2da6f01b1a%40googlegroups.com.

[John A. Tamplin]

A more general answer is that in any community project, whoever cares about a feature the most is the one that designs it, convinces others it is worth including, and implements it.  Just because something has a lot of votes doesn't automatically mean it will get built -- someone has to be interested enough to make it happen.  This was the case even when it was a Google project, but is especially true now that it is fully owned by the community.

--
John A. Tamplin

[James Horsley]

Are there any best practices for open source projects to make integrating back into main GWT easier in the future e.g. license, code style, etc.? If so, it may be worth documenting them somewhere so that projects which are set up with the hope to integrate into GWT if successful can follow those guidelines.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X-MhbBfYZG7nHHWhG%3DOPhBBU3Cc6FaBV5q374vjV9f0Vg%40mail.gmail.com.

[Zied Hamdi OneView]

Hi Goktug and John,

Thanks for your answers, here's what I can say to be more explicit in my thoughts

@Goktug

  

 you were basically asking about exposing a method from a class that is not even a public API in the first place, which basically means "please start maintaining the API of some internal implementation detail for my use case"

Usually, internal APIs are in a package named "internal" because they are subject to change and the architecture is still not clear (the first iterations usually). I experienced this in the years 2005 (already at that time) when I was at Omondo and we needed to develop plugin features even using those cutting edge libraries (at our own risks of rewriting at the next eclipse version). The libraries were marked "internal" but were still designed well enough so we were able to use them (that's why I mentioned that the protected access should be the default one in open sources). Naturally everything was not blue sky at that time, but it was great to be able to know that we take risks by using those libraries (marked "internal"), and at the same time to be able to use them (at the same risks as the eclipse team itself).

So to mark a library as "subject to change" or "only for experts" you may write it explicitely in the docs, but I don't see the point of overprotecting the developers by forbidding them to enter the zone, or considering it's too hard and dangerous for them. I pointed the consequences of "forbidding" zones at the first mail here : saying it leads to forking the project. That's definitely not a good strategy to get people consider them selves at home. I prefer warning but letting people do at their own risks, you might be surprised of what the community can do (and as I said, it's completely valid to refuse to treat bugs on a part that is marked as "subject to change"). 

So that's why I proposed to make the necessary methods (not one method, I was talking about roughly 20 classes) accessible from the outside to permit extending GWT in that part (even as independent libraries) without having to fork GWT (or extract those too restricted classes)

@John

      "in any community project, whoever cares about a feature the most is the one that designs it, convinces others it is worth including, and implements it"

I agree with you, I didn't know how it works inside the GWT team, that's why I supposed the most votes features are given more importance. Anyway, what I was asking in that bug was exactly : "to permit access to the class members so I can do a lib that relies on it without having to fork a part of GWT". 

//---------------------------------------------

We left the principal subject and focused on a specific bug, I think it's good to do this but to a certain extent. as long as we don't loose focus on the subject of the post, which is not that tightly related to that bug, even if it was triggered by it. The subject is more "procedural" than technical

I was thinking about Ubuntu that raises the xx.04 versions that are maintainable for some years and the xx.10 versions that are more experimental. Having a similar model for GWT with the community releases and the incubator releases might be an answer to permit both a stable and head and a dynamic community move?... I wouldn't like to reinvent the wheel, I'm wondering what can be done to allow the community to feel like home on the GWT project. Ideally, people should be able to try patches independently (somehow as plugins) and the GWT team can have visibility on the most popular patches that might be candidates to the head version (or are worth thinking on how to specify them cleanly). 

This would imply having versions of the GWT incubator (not a constantly moving trunk) and a system for dependency control (gradle, maven, ant) between both module-module and module-GWT builds. A similar system was used for the browser plugins, which showed to be complicated, especially when modules depended on each other (an app the uses flash that is compatible with a certain version of the browser)

Take as an example what I'm adopting now (for the bug I submitted): I prefer to change the GWT core code locally and maintain my code working on the core code each time a pull a new version than copying the GWT classes to my own library where I will have to do manual comparing of which class became what in the next GWT version (loosing the git history of the files).

[Jens]

Usually, internal APIs are in a package named "internal" because they are subject to change and the architecture is still not clear (the first iterations usually).

IMHO it is totally irrelevant if a package is named internal or not. If the API in that package is public then its public and if that API is useful it will be used no matter what. Just imagine GWT would open up the possibility for custom UiBinder parsers so that custom widgets can provide advanced UiBinder elements. I am pretty sure that 3rd party UI libraries will use such an API even if its "internal" just to provide better experience for users of such libraries. And I am also pretty sure that users of such libraries will not realize (maybe they are not even told) that they now depend on GWT internals and that they can not update GWT if these internals have changed and the libraries they are using have not been updated yet.

So you may guessed it: I believe that using access modifiers to lock down internals is a lot better. You can always unlock it if its reasonable.

I was thinking about Ubuntu that raises the xx.04 versions that are maintainable for some years and the xx.10 versions that are more experimental. Having a similar model for GWT with the community releases and the incubator releases might be an answer to permit both a stable and head and a dynamic community move?... I wouldn't like to reinvent the wheel, I'm wondering what can be done to allow the community to feel like home on the GWT project. Ideally, people should be able to try patches independently (somehow as plugins) and the GWT team can have visibility on the most popular patches that might be candidates to the head version (or are worth thinking on how to specify them cleanly). 

Actually I think the best way to let people try features that are not in GWT trunk is to create a GWT fork at Github and let people know about it. This has already been done a few times (Java 8 support, proof of concept for improved GWT.create(), Gradle build script for project imports, ..). There is a gwt-sandbox project on Github that tries to bundle interesting ideas: https://github.com/WeTheInternet/gwt-sandbox

Also a problem is the fact that the GWT team is actually smaller than you might think. A community patch that introduces a new feature must be maintained and if a community member looses interest in GWT and his/her feature the GWT team is probably the one to pick that up or it becomes unmaintained code like GWT's bean validation. That can become a burden and thats why they prefer new features as independent libraries. If a library is only possible with some changes in GWT then they will listen and see what can be done, however in your case you hit a bad spot with UiBinder.

Take as an example what I'm adopting now (for the bug I submitted): I prefer to change the GWT core code locally and maintain my code working on the core code each time a pull a new version than copying the GWT classes to my own library where I will have to do manual comparing of which class became what in the next GWT version (loosing the git history of the files).

You should create a fork of GWT so you can rebase your patches onto a new GWT release / trunk commit. Thats a lot easier than copying source from GWT into your project. I have done both and the git rebase approach is a ton smoother. 

-- J.

[Zied Hamdi OneView]

IMHO it is totally irrelevant if a package is named internal or not. If the API in that package is public then its public and if that API is useful it will be used no matter what. 

I don't agree with you on this point: when the team designs a solution, they know if it's a solid architecture or if they didn't have time to think about it and there a re big chances these APIs will change drastically in future versions. Sometimes it is also because they're applying a new idea and they don't know how it will evolve (which axis will be the leading axis). So naming packages that are well designed the same way as packages that aren't is a "loss of information". User developers will feel they have been betrayed if they build a big solution on an API that disappears on the next release or completely mutates in a way that they have to rewrite their soft from ground.

So unless all GWT packages are well and maturely thought an no package is done only to solve a problem very specifically then taken the time to rethink (which I doubt). Loosing this information (or not communicating it is definitely a risky choice)

Actually I think the best way to let people try features that are not in GWT trunk is to create a GWT fork at Github and let people know about it. 

Ok, but you know humans: each person will want himself to be glorified, and a person wouldn't like his efforts to be "stolen" and attributed to another person who just forked GWT. That's why, unless the GWT team says: here's an "official" Github fork to post your ideas (the part of: let people know about it). The GWT team might specify it's a fork made by the community for the community : the fact it is somehow certified as the "official" GWT fork changes a lot of things in comparison to if I said to everyone: it's "My Fork" come and put your effort in it, I will be rewarded for your efforts. 

As I started this discussion by saying that if everybody starts forking GWT we will loose the synergy, and proposed to brainstorm on "the procedure" to avoid that, it's no surprise that when you argue that "everyone should fork GWT and make people know about it" I will not agree :)

[Zied Hamdi OneView]

There are a lot of working collaborative models out there, with more or less top control: my best examples are stackoverflow and wikipedia. There are disadvantages in their solution but it works.

I know source code is not as granular as a wikipedia article, or a stackoverflow question. But you can already see in stackoverflow that if a person asks an alredy asked question his question is kind of 'rejected' (unvoted, marked as duplicate or unanswered). So people are aware and fight dependencies in a quite less firmly tighted platform than our target (in source code you can see dependencies a lot better than in a question forum)

Even Google organizes the Google summer of Code where students contribute to different open source projects, but at the same time in an centrally organized manner (so good profiles can be detected and given wider responsibilities)... the same could apply for this fork 

[Goktug Gokdogan]

I don't want to dive into this discussion but for anyone reading this thread in the future;

Most of the "rebind" packages in GWT are not designed as a public APIs or built with extensibility in mind; they are not meant to be extended nor being maintained across different versions. Things have disappeared before and can disappear again without any notice (unless explicitly documented otherwise).

It is just unfortunate that they don't follow the 'impl' pattern like the other parts of the SDK (i.e. client/shared/server).

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/0993daeb-4c30-44c4-8fdf-701413d9b058%40googlegroups.com.

[Thomas Broyer]

On Wednesday, May 21, 2014 10:54:51 PM UTC+2, Goktug Gokdogan wrote:

I looked at the issue tracker.

To give you some background; UiBinder code base is quite complex, has so many features that it is really hard to maintain. And usually touching one place can easily break other places, so we usually try to prevent it to grow organically by all different request flowing on us.

On the other side, in the issue tracker you were basically asking about exposing a method from a class that is not even a public API in the first place, which basically means "please start maintaining the API of some internal implementation detail for my use case". The quick answer for that, given the state of UiBinder, is 'no'; that is basically I think where Thomas is coming from.

Things that motivated my response:

* asks for a solution to an unknown problem, rather than exposing the problem and trying to find the best solution (which I believe is not the one suggested in the issue)

* worse, it's not even a request for "please make UiBinder extensible" (for whatever definition of "extensible"), it's a "please get out of my way so I can hack around" kind of request (I know the problem was –briefly, vaguely– discussed in the GWT user group, but wasn't reflected in the request on the issue tracker)

* there had been previous decisions related to the (non-)extensibility of UiBinder

* UiBinder internals have changed dramatically in the past (e.g. when switching to SafeHtmlTemplates, almost everything got rewritten; then when introducing UiRenderer, then when tentatively introducing Renderable; there was also an attempt to replace the use of getElementById with walking the DOM, eliminating the use of temporary IDs on elements, or even placeholder elements in some cases); opening them for public consumption is a no-go on those grounds (similar to what you were saying)

* generators (and linkers) are not designed for extension; they're an implementation detail (as you said later in this thread). The public API is in the form of a base interface that you give to GWT.create(). There are exceptions, but they're well documented (CrossSiteIframeLinker, ResourceGenerator for ClientBundle, CustomFieldSerializer for RPC, and –but I'm not even sure– ServiceInterfaceProxyGenerator's createProxyCreator() method; that's all AFAICT) and specifically designed for extensibility without exposing (too much of) the internals.

On the other hand, you can just start a thread in one of the discussion groups, ask and brainstorm different extensibility options, evolve the idea and propose a change in gwt-contributor group. That's probably the best way to achieve your goal and sound reasonable to me.

+1 

[Zied Hamdi OneView]

* asks for a solution to an unknown problem, rather than exposing the problem and trying to find the best solution (which I believe is not the one suggested in the issue)

* worse, it's not even a request for "please make UiBinder extensible" (for whatever definition of "extensible"), it's a "please get out of my way so I can hack around" 

* just Google "authorization in gwt" and you will see the problem doesn't have to be presented anymore, everyone knows it's not supported (it's definitely not an unknown problem Thomas)

* It's a pitty you interpreted the request for making the library extendable for the community as a personal attack, I think it's legitimate to criticize code as long as it is constructive and can help have a better product 

* there had been previous decisions related to the (non-)extensibility of UiBinder

So the problem is known and requested

 

* UiBinder internals have changed dramatically in the past (e.g. when switching to SafeHtmlTemplates, almost everything got rewritten; then when introducing UiRenderer, then when tentatively introducing Renderable; there was also an attempt to replace the use of getElementById with walking the DOM, eliminating the use of temporary IDs on elements, or even placeholder elements in some cases); opening them for public consumption is a no-go on those grounds (similar to what you were saying)

You're right, the source code has a lot of scenarios and is difficult to understand, but it shouldn't mean "no one is allowed to use it apart GWT members", if we consent to use it despite its complexity and risk of having it changed, then we might have a good reason for that

* generators (and linkers) are not designed for extension; they're an implementation detail (as you said later in this thread). The public API is in the form of a base interface that you give to GWT.create(). There are exceptions, but they're well documented (CrossSiteIframeLinker, ResourceGenerator for ClientBundle, CustomFieldSerializer for RPC, and –but I'm not even sure– ServiceInterfaceProxyGenerator's createProxyCreator() method; that's all AFAICT) and specifically designed for extensibility without exposing (too much of) the internals.

Ok, but this should be used as a friendly warning (to avoid trouble to people, saying "you shouldn't!"), not as a rigid law (giving sanctions to those who try to use it). 

I also think the only valid argument for a class to be non extensible is when it is not well specified (used as a temporary glue). 

As a consequence of this definition, a library cannot remain "not designed for extension" for a too long time. Because if it remains, it may lead to troubles even internally: the person who wrote it may quit, and the own members of the project may have trouble maintaining it. 

From the moment a library/module is well feature specified, there's no need to "hide" parts of it from the public sight. Some parts may be extensible by design and ease the task of extending to user developers because it was thought to be extended there, but other parts that weren't originally thought as extensible might show they actually are...

I'm trying to answer with "general rules" rather than specific points to keep the exchange on general cases, (I sent you a mail Thomas with my answer). 

[Thomas Broyer]

On Friday, May 23, 2014 4:41:28 AM UTC+2, Zied Hamdi OneView wrote:

* asks for a solution to an unknown problem, rather than exposing the problem and trying to find the best solution (which I believe is not the one suggested in the issue)

* worse, it's not even a request for "please make UiBinder extensible" (for whatever definition of "extensible"), it's a "please get out of my way so I can hack around" 

* just Google "authorization in gwt" and you will see the problem doesn't have to be presented anymore, everyone knows it's not supported (it's definitely not an unknown problem Thomas)

The issue of "authorization in gwt" is not unknown (BTW, I don't understand how it's a "problem" and even less how it's a problem "in GWT"; GWT doesn't provide tools specifically for that, but that doesn't mean it cannot be done, just that you have to do it yourself, or with third-party libraries such as AcrIS – I never used it, just stumbled on it a few times).

What I'm saying is that the issue doesn't state the problem you're trying to solve; it just says “I wanted to implement roles in my GWT application.” This is not enough of a problem description to me (just look back at the discussion with Jens to understand what I mean; different people have different expectations of what "roles" are and what they imply).

 

* It's a pitty you interpreted the request for making the library extendable for the community as a personal attack,

I didn't!

I think it's legitimate to criticize code as long as it is constructive and can help have a better product 

* there had been previous decisions related to the (non-)extensibility of UiBinder

So the problem is known and requested

Yes, and the decisions were that @UiField(provided=true), @UiFactory, @UiConstructor and @UiChild were enough to support most use cases, and others could either be built on top of them or just not use UiBinder (at least for the cases where it doesn't fit)

 

* UiBinder internals have changed dramatically in the past (e.g. when switching to SafeHtmlTemplates, almost everything got rewritten; then when introducing UiRenderer, then when tentatively introducing Renderable; there was also an attempt to replace the use of getElementById with walking the DOM, eliminating the use of temporary IDs on elements, or even placeholder elements in some cases); opening them for public consumption is a no-go on those grounds (similar to what you were saying)

You're right, the source code has a lot of scenarios and is difficult to understand, but it shouldn't mean "no one is allowed to use it apart GWT members",

It's not even "apart from GWT members". No one should try to re-use it (and I'm purposefully using "re-use" here). Everyone is free to fork it though. This doesn't apply only to UiBinder.

Forks have a cost, but it's a cost for the maintainer of the fork, not for the maintainers of the original project (and by extension, the whole community: because that means time spent maintaining backwards-compatibility of some obscure APIs used by only a couple users cannot be spent on other things that would benefit everyone).

And I'm not saying that specifically with my "GWT maintainer" hat; I also have to live with these decisions as a user of GWT; it's sometimes frustrating, but I believe it's the right thing to do.

At work, I started bending RequestFactory to specific needs it wasn't designed for, and I had to maintain a fork and contribute patches. The patches took years (literally) to be accepted, and some of them only because I now am the maintainer of RequestFactory (co-maintainer, with Manolo).

 

if we consent to use it despite its complexity and risk of having it changed, then we might have a good reason for that

…and you could then just fork the code.

I'm not talking about forking GWT, but, as you did, copy the classes in your own package and build your own enhanced version of UiBinder.

The cost wouldn't be much different (trade the cost of having to adapt to breaking changes in new versions of GWT which can prevent you from upgrading, with the cost of integrating those changes into your fork at the time you choose to do it and without preventing you from upgrading GWT to benefit from other features and bug fixes).

I believe (and I think it's the general feeling within the GWT team) those kind of forks are healthy; “duplication is far cheaper than the wrong abstraction”.

[Zied Hamdi OneView]

Hi all,

I created this post as I said because I was wondering about the evolution of the process of "feature proposal acceptance". This was triggered by a feature proposal I made that was rejected, but it was only a trigger. 

So to avoid changing the subject and talking about why my proposal was rejected and forgetting to talk about: "what is the best way to accept reject proposals", I created another discussion for the rejected feature request here

We stopped at my proposal to have a GWT official fork for incubating features (explaining that if any other entity than GWT does the fork, it won't be accepted by the community)