On Tue, May 20, 2008 at 2:29 PM, Vasudeva Nori <[EMAIL PROTECTED]> wrote:
> On Tue, May 20, 2008 at 2:15 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > > I agree, IMHO we only want 1 implementation to maintain and modify, if > that > > impl can support multiple DB targets with no extra effort, then thats > good, > > but as a RI shindig should not have to be editing DDL or SQL or Code > > targeted at 10 or more databases, that would generate a > testing/development > > nightmare as Cassie points out. IMHO OOTB, it should just run against > Derby, > > perhaps with a simple pre-loaded dataset, or perhaps with some simple > update > > API/Tool (maybe created using GWT and standard components) > > > > But the trick is to figure out WHICH db shindig will bless. > and what would be the criteria? > > IMO, Instead of precluding people from contributing their favorite > backend container, Shindig could accommodate any backend impl by > including such code as an additional - and optionally downloadable & > buildable - module. > Who maintains these? people contributed them will, or some interested > parties will all. It doesn't work that way. All committers are responsible for any piece of code in the Shindig repository. What you're suggesting is exactly what we were discussing a few days ago, which is the Jakarta model. Shindig can maintain at most a small set of very versatile implementations, not dozens of variants maintained by as many people (none of whom are working on the main code). > > > > Those taking shindig to production, with no existing backend would > probably > > want to take the db layer and replace it with something more scalable. > > > > Anyway, that is what I am targeting. > > Ian > > > > > > > > On 20 May 2008, at 21:50, Cassie wrote: > > > >> I definitely don't think this last bit is a good idea. If we have > >> implementations for all of them then we have to support all of them. > >> Adding a new field would require updating tons of different backends - > >> most of which wouldn't be used in prod. Let's just pick one, all > >> agree, and go with it. And, as long as the db is easy enough for all > >> of our users to run, then we should just delete the current xml state > >> file stuff. One demo impl is enough :) > > > > >
