On Wed, Jun 25, 2008 at 12:13 PM, Chris Chabot <[EMAIL PROTECTED]> wrote:
> I was wondering if it would be ok to add a &container=foo param to the > social requests. I don't think it's necessary -- the container is already in the security token, isn't it? > I've been working on restructuring the configuration system for PHP > shindig, and one of my goals is to make a per-container server config (as is > already possible for the javascript configuration in > shindig/config/<container>.js). Er, why don't you just use this existing per-container configuration? We're already doing that on the java side of things. > I would like to mimic the same kind of setup in PHP, and load the default + > container specific config for each social data request, so that the data > services etc are also configurable per container.. that way you can truly > have one shindig instance do it's thing for multiple social sites. Yep -- this is exactly what we do in the java code, and it was a very intentional design choice. > Now my initial thought was to use the security token for this (the domain > key), however there's a catch 22 in that, and that is that the token decoder > is also a configurable class ... so it's not available before the config is > loaded, and hence the catch 22 :) Ahh -- ok, I see the problem. Adding container=foo is not a bad option then. > So either i have to let go of my plan to make a per-container config for > php shindig, or add the un-encoded container param to the requests. > > What do you guys reckon? Add container=foo! > > > -- Chris > >
