On Thu, Aug 01, 2002 at 09:07:46PM -0300, Marc G. Fournier wrote: > > > Of course my humble but thoroughly biased opinion is that libpq++ be > > marked "legacy." > > No doubt, but, if we didn't "push" one interface over another, then it > would be up to the end-users themselves to decide which one to install ... In theory, yes. In this case, however, I see two arguments for making the distinction anyway:
1. Some people won't want to go to the trouble of comparing available interfaces, so they may default to libpq++ because it's what they found first, or because they find mentions of it as the official C++ interface. I think it would be a shame to have new users default to libpq++ "by accident." I think many users would prefer to rely on the PostgreSQL team's judgment--as they do by choosing Postgres in the first place. 2. I get the impression that libpq++ sort of got stuck before it was completed. For the time being libpqxx appears to have better maintenance prospects. Users will want to be aware of this before making a choice. > Okay, then let's word it another way ... if libpq++ *wasn't* in the > repository and part of the distribution, would you have a) started working > on it sooner? b) would you have made it public earlier? c) would ppl > have started to use it and stop'd using libpq++? I'm not sure there's much point to going into a single example in detail, but for completeness' sake I'll just answer these: a) Yes. b) No, because in my case I was encouraged by team members' endorsement of first my suggestions for libpq++, and later a full replacement. Without that, and without an active libpq++ maintainer around, libpqxx might never have gotten off the ground. c) I'd like to think so, yes--but exposure would have been harder. > Basically, with libpq++ in the distribution, we are endorsing its use, so > if we didn't put libpqxx into the repository, would ppl switch from the > 'endorsed' to the 'unendorsed' version? > > By having libpq++ in the repository, we are adding weight to it that it > wouldn't have if it were outside of the repository, making it more > difficult for 'alternatives' to pop in ... I definitely agree here. See above. > > For the more general case, there's the problem of release management: who's > > going to be taking care of synchronizing releases? This may require some > > new infrastructure, such as a mailing list dedicated to the process, or one > > restricted to subproject maintainers. Or something. This reminds me of another potential complication: how would unbundling affect the licensing situation? Mixing and matching components is good in many ways, but it could complicate the situation for end-users--who probably like to be able to rely on the team's judgment on this issue as well. I feel compelled at this point to admit that I prefer the GPL. This is a personal preference, which I set aside because I wanted and expected libpqxx to become the standard C++ interface. Had these interfaces not been bundled, I would have had less incentive to conform to Postgres' licensing conditions. I think having a different license would have made everyone's life a little harder. Jeroen (and yes, I'm trying to repair my From: lines!) ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
