Dan, can you elaborate on option 2? How would moving the oauthpopup feature to core solve the upgrade problem? Is that simply where the rpcregister would happen container-side? On Aug 21, 2012 7:06 PM, "Ryan Baxter" <rbaxte...@apache.org> wrote:
> I like option 1 but can understand why people would be upset, so option 4 > may be your only option. Although I hope we could do option 1 post 2.5... > > On Tue, Aug 21, 2012 at 11:17 AM, Dan Dumont <ddum...@us.ibm.com> wrote: > > > I've been looking at having the oauth popup feature make some calls into > > the container over rpc to handle the popup for various reasons, one of > > which is to work around browser popup blockers. > > The container could implement the feature as a litebox instead of a > popup. > > > > This change though requires some changes that will probably break > > unsuspecting upgraders... so my options are as follows: > > > > 1) Refactor oauthpopup and break unsuspecting containers when they > > upgrade. > > 2) Refactor oauthpopup and add it to core (it's pretty small) so that no > > one gets hurt on the upgrade. > > 3) Refactor oauthpopup and add only the container part to core (this gets > > kinda messy... ) > > 4) LEAVE MY OAUTHPOPUP ALONE! (mess with my own copy, but don't change > > shindig) > > Btw, the default implementation in my refactor calls window.open just > like > > the old one, only now the container is doing the window.open instead of > > the gadget. > > > > What does the community think the best approach would be? >
