Josh Berkus wrote:
> Thomas,
>
>
>> Finally assume that the community board, when similar proposals
>> arrive, will encourage the proposing parties to merge on the thesis
>> that cooperation is far more productive than a beauty contest (well
>> most of the time anyway).
>>
>
> Ah, so you're planning on merging with PL/J?
>
>
That would be a natural consequence, yes. Some synergies with the JDBC
client driver should also be exploited.
> The different solutions are different because of technical decisions
> which they made differently, usually for very good reasons. Slony-I
> is trigger-based, Mammoth is log-based, and no matter which you prefer
> they're not going to merge code.
>
>
They don't need to. Please read my previous postings on this. I'm not
talking about merging code. Sure, when synergies exists, they should be
exploited and when a coherent API can be created that span multiple
solutions, that's great. But that's not the main point. The main point
is to get rid of ambiguities and create a stable, endorsed portfolio
that contains all functionality that is available today.
> BTW, our replication/clustering solutions include:
>
> Slony-I
> pgPool
> Mammoth*
> Postgres-R
> pgCluster
> Sequoia/p|cluster*
> dbMirror/eRserv/other older solutions
> ExtenDB*
> Bizgres MPP*
> Windows/Red Hat/Solaris clustered FS*
>
> (*=proprietary/external)
>
>
Proprietary solutions must be ruled out unless they change their license
and give everything away. That might be an option that would appeal to
some. I know it has happened in other projects. In exchange for an
official contributor status, you give your stuff away. But there's no
place where you can do that today. Submitting your project to PgFoundry
where you compete with other projects ranging from early prototypes to
well established solutions does not give you the right incentives.
> I think any community packaged distribution should encourage this
> diversity, not try to crush it.
>
>
Although diversity can be great in many situations, it's also known to
introduce ambiguities. And that is a pain for the end-user. Especially
when you don't know the quality of the solutions. So, although I agree
that nothing should be "crushed", I still think it's important to
encourage quality, collaboration, communication, and cooperation and
discourage head-on competition. 10 replication solutions is a terrible
waste of resources IMHO. No one size fits all of course, but how many
sizes is really needed?
Regards,
Thomas Hallgren