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 >> > >
