Hey Quentin, > For selective undos and merging, did you read the Mark and Retrace paper(s)? > See > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.9726&rep=rep1&type=pdf > No, I haven't had a look at mark & retrace yet. I'll check it out.
> For merging an old operation, Mark and Retrace (or Address Space > Transformation) doesn't compute/derivate a new operation that is valid in the > current context (the OT way), but simulates an adjusted context in which the > old operation can be executed. I use 'context' (e.g. the position of the > objects in an array) as a synonym for 'space'. > It sounds simpler than OT, no need to support the complex transpose > operation. I'm not yet sure that the Mark and Retrace approach as the same > flexibility than OT. Various recent papers discusses how to improve it > though. Recent ones include: > - > http://research.microsoft.com/en-us/um/redmond/groups/connect/cscw_10/docs/p159.pdf > - http://www.scientific.net/AMR.97-101.3314 and > http://www.computer.org/portal/web/csdl/doi/10.1109/CSCWD.2009.4968039 (I > haven't read these) > The last ones are about a CAD app, so it might be interesting to see how they > cope with the complexity of such an application. Cool. Btw, this is the technique I'm currently implementing for doing live collaboration: http://neil.fraser.name/writing/sync/ I really like this one; I think it's easy to convince yourself that it works. :-) >> In terms of implementation I'm using my CoreObject rewrite for persistence, >> and EtoileFoundation's metamodel code. > > It's great to see the metamodel used a bit. On this topic, I have been > working lately on a Model Builder application that lets you manage, > instantiate and edit both model descriptions and model objects at runtime. > I'm currently writing code to save/open model descriptions and repositories > with EtoileSerialize. Once this is done, I plan to switch to CoreObject and > use this app as intermediate step to see how CoreObject needs to evolve in > order to support compound document persistence. > A model description model involve several description objects, hence the > model is more complex than the one in Mélodie (or any other manager app > model), but still much simpler than a EtoileUI item tree. So I think it's > probably a pretty good test case. > I'll commit this ModelBuilder soon btw. Sounds great. I think model description will turn out to be a really powerful tool, especially for supporting compound documents. One thing I experimented with was writing a copy operation that uses the model description to do a smart copy. Here's a version I sketched out: (it's in ProjectDemo, but I haven't really tested it) - (id)copyWithZone: (NSZone*)zone { COObject *newObject = [[[self class] alloc] initWithModelDescription: _description context: _ctx]; for (ETPropertyDescription *propDesc in [[self modelDescription] allPropertyDescriptions]) { if (![propDesc isDerived]) { id value = [self valueForProperty: [propDesc name]]; if ([propDesc isComposite]) { id valuecopy = [value copyWithZone: zone]; [newObject setValue: valuecopy forProperty: [propDesc name]]; [valuecopy release]; } else { [newObject setValue: value forProperty: [propDesc name]]; } } } return newObject; } It copies only non-derived properties, does a recursive copy on properties which are 'composite', and just copies the pointer to other properties. (although, I see one problem - we usually want to treat primitive objects (NSString NSNumber etc) as part-of the object, so a copy should be made of the,.) To me, it seems like the natural way to write -copy.. and makes me think that trying to implement copy as either "deep copy" or "shallow copy" is a hack for people who don't have a metamodel. :-) Cheers, Eric _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
