A lot of the discussions about guice, etc, seem to be pointing at a disconnect about what Shindig is or how Shindig is expected to be used. I think we should clarify this.
I know that Henning sees it as a library or framework, for instance, like Struts (or Wicket, for the more modern folks). Personally, I see Shindig primarily as a product, like Tomcat or PostgreSQL. Henning's vision reflects how we (Ning) presently use it, largely as an artifact of the state Shindig was in at the time we froze (well, internally branched) to get our current opensocial implementation out. While I think this model is eminently practical for the state Shindig was (is?) in, I don't believe it is the right way to do it. A much better model, to my mind, is to have the primary path be to have Shindig as a standalone service into which you can provide your changes. The better anology is probably like the apache httpd server or jetty. Out of the box they work as standalone servers for most cases (given correct configuration), but you can very easily extend, change, heck warp them into almost anything else if you need to. One model of achieving this (though it makes me queasy) would be to distribute Shindig primarily as a .war and have it do jndi lookups for the deployment specific things, and configuration items, it needs. I suspect I am going out on a pretty stable limb saying that I doubt this fits neatly into any current user's deployment scheme, but it does meet, I believe, the vast majority of needs in a succinct and well understood, if not shiny, way. It might behoove us to come to some agreement on *how* we expect folks to use Shindig, and then tell folks that :-) -Brian
