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. > 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 :) > >
