On Wed, Jun 25, 2008 at 4:26 PM, John Panzer <[EMAIL PROTECTED]> wrote:
> Why not base this on the host:port combo? Because you could run multiple containers on the same host, with different paths. The container=foo solution has worked well for gadget rendering so far, there's no reason to invent a new mechanism (plus, it'll just confuse people if there are two ways to do it). > > > John Panzer (http://abstractioneer.org) > > On Wed, Jun 25, 2008 at 3:33 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > On Wed, Jun 25, 2008 at 3:06 PM, Chris Chabot <[EMAIL PROTECTED]> wrote: > > > > > Well i'm not saying there is a burning need for it right now .. the > only > > > situation where i have 2 different backends is on my development box, > > where > > > i have default (== sample xml file stuff) and partuza (== db driven > one). > > > > > > And now you see the reason why I added this functionality in the java > > implementation in the first place :) > > > > > > > > > > > > > However there is a need to be able to have a seperate 'local config > file' > > > that lives outside of SVN, so it doesn't svn refuse to download the new > > > config file (possibly with new keys) when people svn update ... because > > > config.php has local modifications. So a second outside-of-svn config > > file > > > would solve this. > > > > > > When i was working on that, i thought 'why not do it right, and make > this > > > really configurable', ie not just one seperate local config file, but a > > file > > > per container ... would be better from the flexibility perspective. > > > > > > For now i'll just finish the local config file idea, and make sure it's > > > prepared for eventually being used for a per container config. > > > > > > Ps, it would have just been more consistent with how the javascript > > > configuration works, so would've made a logical way to go > > > > > > -- Chris > > > > > > > > > On Jun 26, 2008, at 12:00 AM, Ropu wrote: > > > > > > hmm, is good, but will be a stuff for the a "generic" shindig that > many > > >> containers will use? > > >> > > >> something like what gmodules.com was in th beginning for the gadget > > >> stuff? > > >> > > >> are there any *real* needs for that yet? > > >> > > >> but saying this, is just adding one param in the iframe url. and you > can > > >> always set a default=container to keep backwards compatibility... > > >> > > >> my 2 cents > > >> > > >> ropu > > >> > > >> On Wed, Jun 25, 2008 at 4: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'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). > > >>> > > >>> 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. > > >>> > > >>> 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 :) > > >>> > > >>> 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? > > >>> > > >>> -- Chris > > >>> > > >>> > > >>> > > >> > > >> -- > > >> .-. --- .--. ..- > > >> R o p u > > >> > > > > > > > > >
