Why not base this on the host:port combo? 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 > >> > > > > >
