I think the main point we made a while back already, was to try to
keep any DB bits out of shindig.
I went and made a side project partuza (see http://www.chabotc.com/partuza/
for more info), with a slight fix in the way the security token
works, this should work perfectly on the java version as well, so
might make a good 'live, db driven' test case? That was (one of the)
intention anyhow.
-- Chris
On May 21, 2008, at 12:10 AM, Kevin Brown wrote:
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 :)
