geda-developers team mailing list archive

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

> On Tue, 18 Dec 2012 20:27:31 +0000, Peter Clifton <pcjc2@xxxxxxxxx>
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 <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre