Activity

on the php side of things, there are 2 places for this (which imo is 1 to many):
shindig/config/container.js and
shindig/php/config/container.php

i'd be more then happy to base the path construction of the one on the other (doesn't matter so much to me which is the master in this regard, having it in the php config would be easier for the end users, but if that would affect consistency between the 2 versions, imo that's not a sacrifice worth making)

Chris Chabot
added a comment - 09/Oct/08 08:18 on the php side of things, there are 2 places for this (which imo is 1 to many):
shindig/config/container.js and
shindig/php/config/container.php
i'd be more then happy to base the path construction of the one on the other (doesn't matter so much to me which is the master in this regard, having it in the php config would be easier for the end users, but if that would affect consistency between the 2 versions, imo that's not a sacrifice worth making)

1. Consistency between client and server configuration
2. Consistency between Java & PHP implementations
3. Consistency in our support for deployments that need to support multiple containers.
4. Consistency in locating configuration options.

Ideally, I'd like the only PHP or java-specific configuration to be pointers to the locations of the features.xml & container configuration files, and details that are actually language specific and simply don't exist in other implementations. Anytime where we have to document two different ways to configure the same thing, it hurts our users.

Kevin Brown
added a comment - 09/Oct/08 18:04 My vote is for putting into container config, for 4 reasons:
1. Consistency between client and server configuration
2. Consistency between Java & PHP implementations
3. Consistency in our support for deployments that need to support multiple containers.
4. Consistency in locating configuration options.
Ideally, I'd like the only PHP or java-specific configuration to be pointers to the locations of the features.xml & container configuration files, and details that are actually language specific and simply don't exist in other implementations. Anytime where we have to document two different ways to configure the same thing, it hurts our users.

jeremi Joslin
added a comment - 17/Nov/08 07:29 This patch move the configuration of the content-rewrite from the shindig.properties to the container.js in shindig java.
It also enable to have different rewriting for each container.
Can anyone review it?

Kevin Brown
added a comment - 17/Nov/08 07:40 I have a family emergency and will not be available regularly this week.
Contacts:
Production release issues: opensocial-sre, lryan
Sandbox issues: opensocial-eng, awiner

Karl Matthias
added a comment - 16/Jan/09 18:40 The PHP Readme is also out of date on this issue. If I hadn't found this bug with the correct information I could not have set up the server in a path other than webroot.