Hey Eric,

Le 20 juil. 2010 à 22:32, Eric Wasylishen a écrit :

> I finally committed some code I've been working on for a while at 
> http://svn.gna.org/svn/etoile/branches/ericwa/ObjectMerging/
>
> The README gives a little introduction. It's basically my rethinking  
> of how to implement CoreObject, along with some research I did on  
> how to do object graph diff / merge with a CoreObject style object  
> graph. Because our objects are labelled with UUID's, it turns out to  
> be really easy (compared with a general XML diff/merge, which  
> involves a lot of guesswork). I'm not doing anything novel, but I  
> think the results will be very nice (with a simple implementation,  
> too.)
>
> I'd be glad to hear what you guys think.

I took a quick look at the code yesterday and I started to read the  
papers mentioned in the README. I'm not sure this reimplementation is  
what we want but I really like the result. Using a delta compression  
based on model edit operations to record the history is really neat  
btw :-)
Once I have put some thoughts into the merging support, I'll post a  
real reply. Probably in the coming days.

At first sight, the existing CoreObject and the reimplementation might  
be closer than I thought initially. I mean operations are implemented  
as classes in the reimplementation and as methods in the existing  
CoreObject in a kinda dual way. If CoreObject as its stand currently  
was restricted to COObject/COGroup strictly, they would be almost  
identical since everything would revolve around operations such insert/ 
remove/update (-addObject:, -removeObject: and - 
setValue:forProperty:). COObject in the reimplementation could even  
support transparent persistency by wrapping it with proxy that  
automatically calls -commit for the methods mentioned just before.

A problem I would worry about in the reimplementation is its scability  
with complex compound documents (e.g. a map edited with a vector  
drawing app). For technical graphics documents, a tree structure that  
contains 10 000 nodes and several objects as properties per node  
doesn't seem unexpected. Computing the entire object graph diff in a  
less than 100 ms sounds impossible. How would you handle such a case?

You also say selective undo support is planned but you don't explain  
how… ?

Cheers,
Quentin.



_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev

Reply via email to