For PHP, the logical thing is to use http://us3.php.net/pdo, and then run whatever as a separate process.
That's pretty standard LAMP stuff. You won't have it available for the tests, though, so a mocked pdo would be appropriate. On Tue, May 20, 2008 at 5:43 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: > Chris, > > If we were to choose Derby on the Java impl to provide the canonical > implementation in Shindig what do you think an appropriate platform would > be > for PHP (sqlite, postgres, mysql ...?) It would obviously be highly > desirable for the canonical Derby data-dump format to be importable into > the > PHP complement. It seems like there isnt a practical choice that isnt GPL > so > would it be OK for this to be a 'recipe' for PHP folks as opposed to > comitted stuff in the Shindig repo? > > -Louis > > On Tue, May 20, 2008 at 3:58 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > > > Good point, all it needs is clean interfaces in the core shindig code, > and > > then anyone could provide an implementation. Thats more distributed. As > long > > as its easy for someone downloading for the first time to get up and > > running. Thats what was so good about Jackrabbit (for me at least), I > could > > download and evaluate it with real data OOTB after a simple build. > > Ian > > > > > > > > > > On 20 May 2008, at 22:29, Vasudeva Nori 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. > >> > >> 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 :) > >>>> > >>> > >>> > >>> > > >
