Option 3 I think.
trunk/conf/shindig.java.properties
or maybee
trunk/conf/shindig.properties
if the settings really are shared between php and shindig.
Ian
On 25 Sep 2008, at 18:05, Brian Eaton wrote:
OK, three ways to do this:
1) Have social-api depend on java/gadgets/conf/gadgets.properties to
locate the container.js file
2) Have social-api hard code the location of
shindig.containers.default in a Guice module.
3) Rename java/gadgets/conf/gadgets.properties to
shindig/config/shindig.java.properties (or another suitable path, if
you prefer)
Any preference? If you leave it to me I'll go with option 1 or option
3, depending on my mood. =) I'll go with option 1 if I'm feeling
lazy, option 3 if I'm feeling disruptive. =)
On Thu, Sep 25, 2008 at 2:36 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
Ok that makes sense to me.
Ian
On 25 Sep 2008, at 17:24, Kevin Brown wrote:
On Thu, Sep 25, 2008 at 11:17 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
Having done a *bit* of work in social-api, I have no objections.
I assume that this would not generate a dependency on gadgets from
social-api, but would generate a dependency on common (already
there) and
a
load of properties in social-api. I think it would be quite
confusing to
have config for social-api inside the gadgets tree ?
The configuration is shared between the java and php code, it's
not in the
gadgets tree. It's in trunk/config.
There is a properties file in the gadgets tree for system wide
settings,
but
honestly most of those should be moved into container config as
well (with
some minor exceptions).
Ian
On 25 Sep 2008, at 16:21, Louis Ryan wrote:
I don't have any major objections. The need is obvious, we can
quibble
over
the details later.
On Thu, Sep 25, 2008 at 1:19 PM, Brian Eaton
<[EMAIL PROTECTED]> wrote:
On Thu, Sep 25, 2008 at 11:46 AM, Kevin Brown
<[EMAIL PROTECTED]> wrote:
Again, though, we could always re-invent per-container
configuration
for
the
umpteenth time that this discussion has come up, but we'll
just come
back
to
the same conclusion. We've proven time and time again that per
container
configuration is necessary because many implementations need to
support
more
than one container in their deployment.
Yep, I agree. I'd like to see somebody who works on the
social-api
ack that this is the right thing to do before I check in a new
dependency.
