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