Woof! On Mon, 30 Nov 2009 07:08:16 -0500, Scott Lawrence <[email protected]> wrote:
> On Sun, 2009-11-29 at 19:30 -0500, Paul Mossman wrote: >> But also how about replicating only the delta when there's a change? > > Yes, ultimately that will be required. When fewer than half the rows in > the table are modified, sending the rows to be deleted and the rows to > be inserted will be a real savings. > > I believe that will require some new capability on the sipXconfig > side... I've mentioned it before, and I still think it's a valid approach: Use "git" to generate the diffs of files to be replicated and send the "patch" across the wire. Save the patch as an audit trail of what changes were applied when and by whom. It also provides a (kinda) transaction based way to update a host that has been down for a while...send the patches that system has yet to see and apply them when it comes up...or even suck the files across via a git repos on the sipXconfig host. It also provides a way to rollback changes, or even "branch" a configuration at a particular point in time. Yes, I'm aware that IMDB tables aren't "files" and applying diff's to them would require sipXconfig to generate full files locally in order to do the diff. But it does that in memory already--writing them out and keeping the latest around for a diff doesn't seem to difficult. --Woof! _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
