> On Tue, 18 Dec 2012 20:27:31 +0000, Peter Clifton <[email protected]> wrote: >> On Tue, 2012-12-18 at 19:58 +0000, Peter TB Brett wrote: >> We should also adopt as many good ideas as possible from other EDA >> tools, like e.g. Upverter (which appears to use operational >> transformations, i.e. a very good idea) [2]. > > That might be a nice way to do local multi-process editing of the same > document. The nasty complex theory stuff needs to get abstracted away > though, as it may need someone smarter them me to understand the compsci > details! (The wikipedia page is intimidating at first glance).
As I understand it, it's fairly simple to implement a basic OT set up iff you can represent all your primitive operations as list insertions or deletions. This paper (which I am currently reading in the hope of improving my understanding but also because it's very interesting) seems to have a much clearer description than the WP page: http://dx.doi.org/10.1109%2FTPDS.2007.35 >> Additionally, see this (also incomplete) diagram [3]. You can tell it >> is old because it doesn't include polygons. ;-) > > I remember that ;) > > The key controversial idea there which differs from gEDA is relating to > attributes. > > PLEASE can we make attributes a fundamental property, and the text > representation thereof DISTINCT! ??? I have no problem with that. > [snip] > > Anyway.. I think concurrent programming is the way forward for any kind > of data-based tasks in the future. Definitely! It's the only way to survive the ongoing gradual migration from systems with a small number of fast processors to systems with a large number of slow processors. Peter -- Peter Brett <[email protected]> Remote Sensing Research Group Surrey Space Centre -- Mailing list: https://launchpad.net/~geda-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~geda-developers More help : https://help.launchpad.net/ListHelp
