Re: Time to scale up?

[Thomas Hallgren <thomas(at)tada(dot)se>]

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