Hi Christopher, Le 21 juin 2011 à 14:43, Christopher Armstrong a écrit :
> Hi Quentin > > On Tue, 21 Jun 2011 14:07 +0200, "Quentin Mathé" <qma...@gmail.com> > wrote: >>>> I've put together some patches for ObjectMerging4 that: >>>> 1) Add makefiles for GNUstep >>>> 2) Fix compilation errors >>>> 3) Add primitive value persistence >>>> >>>> Please find them attached at: https://gna.org/patch/index.php?2652 >> >> Can I apply these patches to you branch? I'd like to start hacking on the >> compound document editor soon. > > I applied them in my own branch. I will not be working on this stuff > until after 3 July as I am on holidays until that time. ok > By the way, I'll > be in England briefly on 30 June/1 July. I'm not going to be able to come to London at this time. But if you ever come to Paris, let me know :-) >>> Overall, segregating objects is probably a good idea. My hunch is that it >>> should be mostly an implementation detail and not have any observable >>> effect on the use of the library, but I'm not sure. >> >> This sounds like the discussion we had about embedded core object vs >> standalone/root core objects (aka persistent roots), and the need to >> ensure that other documents usually don't change behind the user's back >> on editing another document, unless it's clear a document kind involves >> explicit sharing. When the persistent root is a compound document, a >> photo group etc. explicit sharing can be expected. iirc To ensure a >> predictable and stable behavior from the user's perspective, iirc we >> concluded that embedded objects must be copied (even if it's a move) when >> inserted into another persistent root, unlike root object which are just >> aliased (through the UUID). > > I also contributed patches that implements object segregation, but I > haven't been able to fully test it due to GNUstep issues at the time. I > think they are in my branch. I took a quick look. Sounds ok if we allow multiple root objects per editing context rather than a single one. With a single one, if you load 20 0000 root objects, you create 20 000 editing contexts too. For object managers, this is going to be a pretty common case I think e.g. browsing a photo library where each photo is a core object. This approach could also make much harder to check relationship consistency and implement history tracks (aggregating the history of several core objects), not sure though… I need to think a bit more deeply about it, but it seems better to keep each editing contexts as a live view on the entire database or a working copy in revision control terminology. For example, this makes easier to have multiple temporal views on the entire database loaded in memory if you want to. Another approach would be to use two kind of editing contexts (or support it as an optional choice): - per root object - per database This could make easier to deal with multiple (compound) documents loaded in memory. In this case, commits must usually concern a single (compound) document and you would avoid to loop on every damaged objects to check whether its root object is the one on which the commit was requested. Given we are going to record changes at a really low granularity, I'm not sure this really matters in term of performance. Even with many (compound) documents in the same memory space, the number of damaged objects should remain pretty low in most commit cases. In the long run, imo each compound document should be insulated in its own process, to ensure a decent memory protection and some basic safety with potential class/category conflicts (ObjC has no namespace/module support currently, so from a safety viewpoint ObjC is a bit troublesome). So we would just run multiple copies of the same 'Document' program (as GNUstep allows it with a special default) with various components loaded lazily based on the compound document need. With this 'compound document in their own process' model, that means we would have a single compound document per editing context, so the commit issue described above would be restricted to non-compound documents (loaded in the same memory space). Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
