Matt I think the timeline for the release should be covered in a
separate thread.    I don't want this thread to loose focus.  I

-Ryan

On Aug 22, 2012, at 4:17 PM, "Franklin, Matthew B." <mfrank...@mitre.org> wrote:

>> -----Original Message-----
>> From: Henry Saputra [mailto:henry.sapu...@gmail.com]
>> Sent: Tuesday, August 21, 2012 7:17 PM
>> To: dev@shindig.apache.org
>> Subject: Re: Changing oauthpopup feature to introduce some container
>> cooperation...
>>
>> Dan,
>>
>> Since we are close to release 2.5 I would vote for option 4.
>
> My first instinct is to agree with Henry that this should wait.  On the other 
> hand, we don't really have a roadmap for 2.5, so I would say weigh the value 
> of the change, over cost of breakage.  I don't think adding it to core really 
> solves anything, so if you are going to change it I would recommend 1 and 
> make sure it is part of the release/upgrade documentation.
>
> Do we have a timeline for 2.5 RELEASE?
>
> My $0.02.
>
>>
>> We have other issues with Shindig to follow OS specs so unless it crucial
>> bug fix I think we should leave it for now.
>>
>>
>> - Henry
>>
>> On Tuesday, August 21, 2012, 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?
>>>

Reply via email to