On Thu, Dec 4, 2008 at 9:49 AM, Brian McCallister <[EMAIL PROTECTED]> wrote:
> 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 :-) [this is only really a relevant discussion for the java implementation; php easily adapts to either use case] I don't see any reason not to have multiple artifacts: - 3 jars for social-api / gadgets/ common - 1 war that pulls everything in. In this way those who want a drop in web service can use the war, and those who need to consume just the code and add their own bits to it can consume the jars. Of course, the fact that everyone who ever touches the java code will most likely have to write implementations of various interfaces and do a bunch of other tweaking anyway tells me that the current user base for the war is effectively zero. I tend to write all code as though I'm writing a library; the parts that convert a library to a server are secondary. > > > -Brian >
