> --=-QQHYShMlxI2BY71i6NiO
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> > 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?
If the various "solutions" may be folded down into a smaller set of programs,
perhaps, ultimately, into _one_ program, that would surely be easier to
manage, in the codebase, than having five or six such programs.
If one program can do the job that needs to be done, and it has not been
_clearly_ established that that is _not_ possible, then I'd think it rather
silly to have a bunch of "replication solutions" that need to be updated any
time a relevant change goes into the database engine.
I'd be surprised if, in the end, there truly _needed_ to be more than about
two approaches.
Should the team plan to _have_ a mess? I'd think not.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://cbbrowne.com/info/linuxdistributions.html
"We don't understand the software, and sometimes we don't understand
the hardware, but we can *see* the blinking lights!" -- Unknown
