social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Brian Eaton <be...@google.com>]

social-api folks: the proposal below for how to configure shindig to
use real security tokens requires that the social-api side of the
shindig tree inject a ContainerConfig object.  The gadgets side of the
code base currently gets the ContainerConfig by:

- reading java/gadgets/conf/gadgets.properties
- extracting shindig.containers.default from that
- injecting a ContainerConfig based on shindig.containers.default.

Any objections to this happening on the social-api side as well?  Is
there an alternative mechanism that would work better?

On Wed, Sep 24, 2008 at 5:03 AM, Kevin Brown <et...@google.com> wrote:
> On Wed, Sep 24, 2008 at 3:11 AM, Brian Eaton <be...@google.com> wrote:
>
>> I just checked in a couple of classes that provide real security
>> tokens, configured per-container.  They are, for the moment, dead
>> code.  I don't want to remove the default usage of
>> BasicSecurityTokenDecoder, because easy testing is too useful.
>>
>> Any thoughts on how Shindig java deployments should opt-in to using
>> these classes?  Hand-written Guice modules?  Configuration in
>> containers.js?
>>
>
> container configuration is the way to go. It's actually pretty easy:
>
> - bind all possible variants with symbolic names (the class names are as
> good as any)
> - decoder code dispatches to appropriate variant based on container name.
>
> Making people write Guice modules is a non-starter. Shindig should be able
> to be used without writing any code.
>

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Kevin Brown <et...@google.com>]

On Fri, Sep 26, 2008 at 12:21 AM, Ian Boston <ie...@tfd.co.uk> wrote:

> Option 3 I think.
>
> trunk/conf/shindig.java.properties
> or maybee
> trunk/conf/shindig.properties
> if the settings really are shared between php and shindig.


The container configuration is shared, it's the properties file (which
points to the container configuration) that isn't. PHP doesn't know (or
care) about properties files.


>
>
> Ian
>
>
> On 25 Sep 2008, at 18:05, Brian Eaton wrote:
>
>  OK, three ways to do this:
>>
>> 1) Have social-api depend on java/gadgets/conf/gadgets.properties to
>> locate the container.js file
>> 2) Have social-api hard code the location of
>> shindig.containers.default in a Guice module.
>> 3) Rename java/gadgets/conf/gadgets.properties to
>> shindig/config/shindig.java.properties (or another suitable path, if
>> you prefer)
>>
>> Any preference?  If you leave it to me I'll go with option 1 or option
>> 3, depending on my mood. =)  I'll go with option 1 if I'm feeling
>> lazy, option 3 if I'm feeling disruptive. =)
>>
>> On Thu, Sep 25, 2008 at 2:36 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>> Ok that makes sense to me.
>>> Ian
>>>
>>> On 25 Sep 2008, at 17:24, Kevin Brown wrote:
>>>
>>>  On Thu, Sep 25, 2008 at 11:17 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>
>>>>  Having done a *bit* of work in social-api, I have no objections.
>>>>>
>>>>> I assume that this would not generate a dependency on gadgets from
>>>>> social-api, but would generate a dependency on common (already there)
>>>>> and
>>>>> a
>>>>> load of properties in social-api. I think it would be quite confusing
>>>>> to
>>>>> have config for social-api inside the gadgets tree ?
>>>>>
>>>>
>>>>
>>>> The configuration is shared between the java and php code, it's not in
>>>> the
>>>> gadgets tree. It's in trunk/config.
>>>>
>>>> There is a properties file in the gadgets tree for system wide settings,
>>>> but
>>>> honestly most of those should be moved into container config as well
>>>> (with
>>>> some minor exceptions).
>>>>
>>>>
>>>>
>>>>>
>>>>> Ian
>>>>>
>>>>>
>>>>> On 25 Sep 2008, at 16:21, Louis Ryan wrote:
>>>>>
>>>>>  I don't have any major objections. The need is obvious, we can quibble
>>>>>
>>>>>>
>>>>>> over
>>>>>> the details later.
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 25, 2008 at 1:19 PM, Brian Eaton <be...@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>  On Thu, Sep 25, 2008 at 11:46 AM, Kevin Brown <et...@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>  Again, though, we could always re-invent per-container configuration
>>>>>>>> for
>>>>>>>>
>>>>>>>>  the
>>>>>>>
>>>>>>>  umpteenth time that this discussion has come up, but we'll just come
>>>>>>>> back
>>>>>>>>
>>>>>>>>  to
>>>>>>>
>>>>>>>  the same conclusion. We've proven time and time again that per
>>>>>>>> container
>>>>>>>> configuration is necessary because many implementations need to
>>>>>>>> support
>>>>>>>>
>>>>>>>>  more
>>>>>>>
>>>>>>>  than one container in their deployment.
>>>>>>>>
>>>>>>>>
>>>>>>> Yep, I agree.  I'd like to see somebody who works on the social-api
>>>>>>> ack that this is the right thing to do before I check in a new
>>>>>>> dependency.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Ian Boston <ie...@tfd.co.uk>]

Option 3 I think.

trunk/conf/shindig.java.properties
or maybee
trunk/conf/shindig.properties
if the settings really are shared between php and shindig.

Ian

On 25 Sep 2008, at 18:05, Brian Eaton wrote:

> OK, three ways to do this:
>
> 1) Have social-api depend on java/gadgets/conf/gadgets.properties to
> locate the container.js file
> 2) Have social-api hard code the location of
> shindig.containers.default in a Guice module.
> 3) Rename java/gadgets/conf/gadgets.properties to
> shindig/config/shindig.java.properties (or another suitable path, if
> you prefer)
>
> Any preference?  If you leave it to me I'll go with option 1 or option
> 3, depending on my mood. =)  I'll go with option 1 if I'm feeling
> lazy, option 3 if I'm feeling disruptive. =)
>
> On Thu, Sep 25, 2008 at 2:36 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>> Ok that makes sense to me.
>> Ian
>>
>> On 25 Sep 2008, at 17:24, Kevin Brown wrote:
>>
>>> On Thu, Sep 25, 2008 at 11:17 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>
>>>> Having done a *bit* of work in social-api, I have no objections.
>>>>
>>>> I assume that this would not generate a dependency on gadgets from
>>>> social-api, but would generate a dependency on common (already  
>>>> there) and
>>>> a
>>>> load of properties in social-api. I think it would be quite  
>>>> confusing to
>>>> have config for social-api inside the gadgets tree ?
>>>
>>>
>>> The configuration is shared between the java and php code, it's  
>>> not in the
>>> gadgets tree. It's in trunk/config.
>>>
>>> There is a properties file in the gadgets tree for system wide  
>>> settings,
>>> but
>>> honestly most of those should be moved into container config as  
>>> well (with
>>> some minor exceptions).
>>>
>>>
>>>>
>>>>
>>>> Ian
>>>>
>>>>
>>>> On 25 Sep 2008, at 16:21, Louis Ryan wrote:
>>>>
>>>>  I don't have any major objections. The need is obvious, we can  
>>>> quibble
>>>>>
>>>>> over
>>>>> the details later.
>>>>>
>>>>>
>>>>> On Thu, Sep 25, 2008 at 1:19 PM, Brian Eaton  
>>>>> <be...@google.com> wrote:
>>>>>
>>>>>  On Thu, Sep 25, 2008 at 11:46 AM, Kevin Brown  
>>>>> <et...@google.com> wrote:
>>>>>>
>>>>>>> Again, though, we could always re-invent per-container  
>>>>>>> configuration
>>>>>>> for
>>>>>>>
>>>>>> the
>>>>>>
>>>>>>> umpteenth time that this discussion has come up, but we'll  
>>>>>>> just come
>>>>>>> back
>>>>>>>
>>>>>> to
>>>>>>
>>>>>>> the same conclusion. We've proven time and time again that per
>>>>>>> container
>>>>>>> configuration is necessary because many implementations need to
>>>>>>> support
>>>>>>>
>>>>>> more
>>>>>>
>>>>>>> than one container in their deployment.
>>>>>>>
>>>>>>
>>>>>> Yep, I agree.  I'd like to see somebody who works on the  
>>>>>> social-api
>>>>>> ack that this is the right thing to do before I check in a new
>>>>>> dependency.
>>>>>>
>>>>>>
>>>>
>>
>>

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Brian Eaton <be...@google.com>]

Submitted.  Everything should be backwards compatible with, scream at
me if it isn't.

On Thu, Sep 25, 2008 at 4:01 PM, Kevin Brown <et...@google.com> wrote:
> On Fri, Sep 26, 2008 at 12:52 AM, Brian Eaton <be...@google.com> wrote:
>
>> On Thu, Sep 25, 2008 at 3:37 PM, Kevin Brown <et...@google.com> wrote:
>> > All of those choices are terrible, so it's a good thing they're not the
>> only
>> > options.
>>
>> True, the margaritas at Fiesta del Mar are excellent.
>>
>> > A small guice module can be created to load the properties in common. Add
>> > the module to web.xml and you're done.
>>
>> OK, are you proposing java/common/conf/shindig.properties for the
>> properties location, with a ContainerGuiceModule (please suggest a
>> better name) somewhere in java/common/src/main?
>
>
> PropertiesModule. Feel free to move the current gadgets/conf properties here
> this so that there's only one file to worry about as well.
>

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Kevin Brown <et...@google.com>]

On Fri, Sep 26, 2008 at 12:52 AM, Brian Eaton <be...@google.com> wrote:

> On Thu, Sep 25, 2008 at 3:37 PM, Kevin Brown <et...@google.com> wrote:
> > All of those choices are terrible, so it's a good thing they're not the
> only
> > options.
>
> True, the margaritas at Fiesta del Mar are excellent.
>
> > A small guice module can be created to load the properties in common. Add
> > the module to web.xml and you're done.
>
> OK, are you proposing java/common/conf/shindig.properties for the
> properties location, with a ContainerGuiceModule (please suggest a
> better name) somewhere in java/common/src/main?


PropertiesModule. Feel free to move the current gadgets/conf properties here
this so that there's only one file to worry about as well.

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Brian Eaton <be...@google.com>]

On Thu, Sep 25, 2008 at 3:37 PM, Kevin Brown <et...@google.com> wrote:
> All of those choices are terrible, so it's a good thing they're not the only
> options.

True, the margaritas at Fiesta del Mar are excellent.

> A small guice module can be created to load the properties in common. Add
> the module to web.xml and you're done.

OK, are you proposing java/common/conf/shindig.properties for the
properties location, with a ContainerGuiceModule (please suggest a
better name) somewhere in java/common/src/main?

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Kevin Brown <et...@google.com>]

On Fri, Sep 26, 2008 at 12:05 AM, Brian Eaton <be...@google.com> wrote:

> OK, three ways to do this:
>
> 1) Have social-api depend on java/gadgets/conf/gadgets.properties to
> locate the container.js file
> 2) Have social-api hard code the location of
> shindig.containers.default in a Guice module.
> 3) Rename java/gadgets/conf/gadgets.properties to
> shindig/config/shindig.java.properties (or another suitable path, if
> you prefer)


All of those choices are terrible, so it's a good thing they're not the only
options.

A small guice module can be created to load the properties in common. Add
the module to web.xml and you're done.

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Brian Eaton <be...@google.com>]

OK, three ways to do this:

1) Have social-api depend on java/gadgets/conf/gadgets.properties to
locate the container.js file
2) Have social-api hard code the location of
shindig.containers.default in a Guice module.
3) Rename java/gadgets/conf/gadgets.properties to
shindig/config/shindig.java.properties (or another suitable path, if
you prefer)

Any preference?  If you leave it to me I'll go with option 1 or option
3, depending on my mood. =)  I'll go with option 1 if I'm feeling
lazy, option 3 if I'm feeling disruptive. =)

On Thu, Sep 25, 2008 at 2:36 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> Ok that makes sense to me.
> Ian
>
> On 25 Sep 2008, at 17:24, Kevin Brown wrote:
>
>> On Thu, Sep 25, 2008 at 11:17 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>> Having done a *bit* of work in social-api, I have no objections.
>>>
>>> I assume that this would not generate a dependency on gadgets from
>>> social-api, but would generate a dependency on common (already there) and
>>> a
>>> load of properties in social-api. I think it would be quite confusing to
>>> have config for social-api inside the gadgets tree ?
>>
>>
>> The configuration is shared between the java and php code, it's not in the
>> gadgets tree. It's in trunk/config.
>>
>> There is a properties file in the gadgets tree for system wide settings,
>> but
>> honestly most of those should be moved into container config as well (with
>> some minor exceptions).
>>
>>
>>>
>>>
>>> Ian
>>>
>>>
>>> On 25 Sep 2008, at 16:21, Louis Ryan wrote:
>>>
>>>  I don't have any major objections. The need is obvious, we can quibble
>>>>
>>>> over
>>>> the details later.
>>>>
>>>>
>>>> On Thu, Sep 25, 2008 at 1:19 PM, Brian Eaton <be...@google.com> wrote:
>>>>
>>>>  On Thu, Sep 25, 2008 at 11:46 AM, Kevin Brown <et...@google.com> wrote:
>>>>>
>>>>>> Again, though, we could always re-invent per-container configuration
>>>>>> for
>>>>>>
>>>>> the
>>>>>
>>>>>> umpteenth time that this discussion has come up, but we'll just come
>>>>>> back
>>>>>>
>>>>> to
>>>>>
>>>>>> the same conclusion. We've proven time and time again that per
>>>>>> container
>>>>>> configuration is necessary because many implementations need to
>>>>>> support
>>>>>>
>>>>> more
>>>>>
>>>>>> than one container in their deployment.
>>>>>>
>>>>>
>>>>> Yep, I agree.  I'd like to see somebody who works on the social-api
>>>>> ack that this is the right thing to do before I check in a new
>>>>> dependency.
>>>>>
>>>>>
>>>
>
>

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Ian Boston <ie...@tfd.co.uk>]

Ok that makes sense to me.
Ian

On 25 Sep 2008, at 17:24, Kevin Brown wrote:

> On Thu, Sep 25, 2008 at 11:17 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>
>> Having done a *bit* of work in social-api, I have no objections.
>>
>> I assume that this would not generate a dependency on gadgets from
>> social-api, but would generate a dependency on common (already  
>> there) and a
>> load of properties in social-api. I think it would be quite  
>> confusing to
>> have config for social-api inside the gadgets tree ?
>
>
> The configuration is shared between the java and php code, it's not  
> in the
> gadgets tree. It's in trunk/config.
>
> There is a properties file in the gadgets tree for system wide  
> settings, but
> honestly most of those should be moved into container config as  
> well (with
> some minor exceptions).
>
>
>>
>>
>> Ian
>>
>>
>> On 25 Sep 2008, at 16:21, Louis Ryan wrote:
>>
>>  I don't have any major objections. The need is obvious, we can  
>> quibble
>>> over
>>> the details later.
>>>
>>>
>>> On Thu, Sep 25, 2008 at 1:19 PM, Brian Eaton <be...@google.com>  
>>> wrote:
>>>
>>>  On Thu, Sep 25, 2008 at 11:46 AM, Kevin Brown <et...@google.com>  
>>> wrote:
>>>>
>>>>> Again, though, we could always re-invent per-container  
>>>>> configuration for
>>>>>
>>>> the
>>>>
>>>>> umpteenth time that this discussion has come up, but we'll just  
>>>>> come
>>>>> back
>>>>>
>>>> to
>>>>
>>>>> the same conclusion. We've proven time and time again that per  
>>>>> container
>>>>> configuration is necessary because many implementations need to  
>>>>> support
>>>>>
>>>> more
>>>>
>>>>> than one container in their deployment.
>>>>>
>>>>
>>>> Yep, I agree.  I'd like to see somebody who works on the social-api
>>>> ack that this is the right thing to do before I check in a new
>>>> dependency.
>>>>
>>>>
>>

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Kevin Brown <et...@google.com>]

On Thu, Sep 25, 2008 at 11:17 PM, Ian Boston <ie...@tfd.co.uk> wrote:

> Having done a *bit* of work in social-api, I have no objections.
>
> I assume that this would not generate a dependency on gadgets from
> social-api, but would generate a dependency on common (already there) and a
> load of properties in social-api. I think it would be quite confusing to
> have config for social-api inside the gadgets tree ?


The configuration is shared between the java and php code, it's not in the
gadgets tree. It's in trunk/config.

There is a properties file in the gadgets tree for system wide settings, but
honestly most of those should be moved into container config as well (with
some minor exceptions).


>
>
> Ian
>
>
> On 25 Sep 2008, at 16:21, Louis Ryan wrote:
>
>  I don't have any major objections. The need is obvious, we can quibble
>> over
>> the details later.
>>
>>
>> On Thu, Sep 25, 2008 at 1:19 PM, Brian Eaton <be...@google.com> wrote:
>>
>>  On Thu, Sep 25, 2008 at 11:46 AM, Kevin Brown <et...@google.com> wrote:
>>>
>>>> Again, though, we could always re-invent per-container configuration for
>>>>
>>> the
>>>
>>>> umpteenth time that this discussion has come up, but we'll just come
>>>> back
>>>>
>>> to
>>>
>>>> the same conclusion. We've proven time and time again that per container
>>>> configuration is necessary because many implementations need to support
>>>>
>>> more
>>>
>>>> than one container in their deployment.
>>>>
>>>
>>> Yep, I agree.  I'd like to see somebody who works on the social-api
>>> ack that this is the right thing to do before I check in a new
>>> dependency.
>>>
>>>
>

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Ian Boston <ie...@tfd.co.uk>]

Having done a *bit* of work in social-api, I have no objections.

I assume that this would not generate a dependency on gadgets from  
social-api, but would generate a dependency on common (already there)  
and a load of properties in social-api. I think it would be quite  
confusing to have config for social-api inside the gadgets tree ?

Ian

On 25 Sep 2008, at 16:21, Louis Ryan wrote:

> I don't have any major objections. The need is obvious, we can  
> quibble over
> the details later.
>
>
> On Thu, Sep 25, 2008 at 1:19 PM, Brian Eaton <be...@google.com>  
> wrote:
>
>> On Thu, Sep 25, 2008 at 11:46 AM, Kevin Brown <et...@google.com>  
>> wrote:
>>> Again, though, we could always re-invent per-container  
>>> configuration for
>> the
>>> umpteenth time that this discussion has come up, but we'll just  
>>> come back
>> to
>>> the same conclusion. We've proven time and time again that per  
>>> container
>>> configuration is necessary because many implementations need to  
>>> support
>> more
>>> than one container in their deployment.
>>
>> Yep, I agree.  I'd like to see somebody who works on the social-api
>> ack that this is the right thing to do before I check in a new
>> dependency.
>>

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Louis Ryan <lr...@google.com>]

I don't have any major objections. The need is obvious, we can quibble over
the details later.


On Thu, Sep 25, 2008 at 1:19 PM, Brian Eaton <be...@google.com> wrote:

> On Thu, Sep 25, 2008 at 11:46 AM, Kevin Brown <et...@google.com> wrote:
> > Again, though, we could always re-invent per-container configuration for
> the
> > umpteenth time that this discussion has come up, but we'll just come back
> to
> > the same conclusion. We've proven time and time again that per container
> > configuration is necessary because many implementations need to support
> more
> > than one container in their deployment.
>
> Yep, I agree.  I'd like to see somebody who works on the social-api
> ack that this is the right thing to do before I check in a new
> dependency.
>

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Brian Eaton <be...@google.com>]

On Thu, Sep 25, 2008 at 11:46 AM, Kevin Brown <et...@google.com> wrote:
> Again, though, we could always re-invent per-container configuration for the
> umpteenth time that this discussion has come up, but we'll just come back to
> the same conclusion. We've proven time and time again that per container
> configuration is necessary because many implementations need to support more
> than one container in their deployment.

Yep, I agree.  I'd like to see somebody who works on the social-api
ack that this is the right thing to do before I check in a new
dependency.

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Kevin Brown <et...@google.com>]

On Thu, Sep 25, 2008 at 8:38 PM, Brian Eaton <be...@google.com> wrote:

> On Wed, Sep 24, 2008 at 6:30 PM, Kevin Brown <et...@google.com> wrote:
> > The social-api code already depends on ContainerConfig (by way of auth
> > code). We could always re-invent the container mechanism for the 4th or
> 5th
> > time though.
>
> I'm not seeing this dependency.  The social-api service does not
> inject a ContainerConfig object, nor is there any code enabled by
> default in shindig-common that requires a ContainerConfig.


Not by default (currently), but yes, it's there -- the blob crypter based
token wouldn't work without it.

Again, though, we could always re-invent per-container configuration for the
umpteenth time that this discussion has come up, but we'll just come back to
the same conclusion. We've proven time and time again that per container
configuration is necessary because many implementations need to support more
than one container in their deployment.

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Brian Eaton <be...@google.com>]

On Wed, Sep 24, 2008 at 6:30 PM, Kevin Brown <et...@google.com> wrote:
> The social-api code already depends on ContainerConfig (by way of auth
> code). We could always re-invent the container mechanism for the 4th or 5th
> time though.

I'm not seeing this dependency.  The social-api service does not
inject a ContainerConfig object, nor is there any code enabled by
default in shindig-common that requires a ContainerConfig.

Re: social-api requiring ContainerConfig [WAS Re: configuring real security tokens]

[Kevin Brown <et...@google.com>]

On Thu, Sep 25, 2008 at 3:17 AM, Brian Eaton <be...@google.com> wrote:

> social-api folks: the proposal below for how to configure shindig to
> use real security tokens requires that the social-api side of the
> shindig tree inject a ContainerConfig object.  The gadgets side of the
> code base currently gets the ContainerConfig by:
>
> - reading java/gadgets/conf/gadgets.properties
> - extracting shindig.containers.default from that
> - injecting a ContainerConfig based on shindig.containers.default.
>
> Any objections to this happening on the social-api side as well?  Is
> there an alternative mechanism that would work better?


The social-api code already depends on ContainerConfig (by way of auth
code). We could always re-invent the container mechanism for the 4th or 5th
time though.


>
>
> On Wed, Sep 24, 2008 at 5:03 AM, Kevin Brown <et...@google.com> wrote:
> > On Wed, Sep 24, 2008 at 3:11 AM, Brian Eaton <be...@google.com> wrote:
> >
> >> I just checked in a couple of classes that provide real security
> >> tokens, configured per-container.  They are, for the moment, dead
> >> code.  I don't want to remove the default usage of
> >> BasicSecurityTokenDecoder, because easy testing is too useful.
> >>
> >> Any thoughts on how Shindig java deployments should opt-in to using
> >> these classes?  Hand-written Guice modules?  Configuration in
> >> containers.js?
> >>
> >
> > container configuration is the way to go. It's actually pretty easy:
> >
> > - bind all possible variants with symbolic names (the class names are as
> > good as any)
> > - decoder code dispatches to appropriate variant based on container name.
> >
> > Making people write Guice modules is a non-starter. Shindig should be
> able
> > to be used without writing any code.
> >
>