Greg Copeland <[EMAIL PROTECTED]> writes:
> > As I said -- I don't really see the need for a bunch of replication
> > implementations, and therefore I don't see the need for a generic API
> > to make the whole mess (slightly) more manageable.
>
> I see. So the intension of the core developers is to have one and only
> one replication solution?
Not being a core developer, I can't comment on their intentions.
That said, I _personally_ don't see the need for more than one or two
replication implementations. You might need more than one if you
wanted to do both lazy and eager replication, for example. But you
certainly don't need 5 or 6 or however many implementations exist at
the moment.
I think the reason there are a lot of different implementations at the
moment is that each one has some pretty serious problems. So rather
than trying to reduce the problem by making it slightly easier for the
different replication solutions to inter-operate, I think it's a
better idea to solve the problem outright by improving one of the
existing replication projects to the point at which it is ready for
widespread production usage.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]>
PGP Key ID: DB3C29FC
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
