http://partuza.chabotc.com
http://partuza.us.chabotc.com
http://partuza.chabotc.nl
all container = partuza (thats how its configured in shindig/container/
<foo>.js too), and that's also the container name used when signing
oauth requests etc... Would really be a bore to have to create so many
config files :)
Of course this is a relatively silly example, but i think social
network sites have multiple host names for their site more often
However i'm not completely discarding the option, or some variant of
it .. does make for less code changes which sometimes is good :)
-- Chris
On Jun 26, 2008, at 1:26 AM, John Panzer wrote:
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
