Hey Quentin, >>> 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 think that sounds good.. but I'm not totally sure. > > We can begin with a model that involves explicit root objects… If we figure > out it's possible to remove the explicit root object support and still meet > our needs or the same behavior, then we can remove it. I don't think that > would imply many changes in the overall design and implementation.
I agree. >> If you consider photos, I think the design used with iPhoto is good - within >> the library, photos are aliased/shared when you move them around, create >> groups, etc., but if you import or export from the library, a copy is >> created. > > It depends what you mean by import/export. Is it about foreign world > compatibility, in other words importing/exporting to/from a CoreObject > database, or is it about some import/export notion within a CoreObject > database? > For my next replies below, I'll assume it's the second case. >> Maybe if we wanted to emulate that, we would just make the library a >> persistent root, and the photos would be embedded objects. > > Hm, I'm not sure to see what the common use case could be… Any example? > I meant the second case; maybe import/export isn't the right term. The use case I was thinking of is how on OS X you can collect media in your Downloads folder (or other folders), and drag interesting ones to your iphoto/itunes library. In OS X terminology it's importing the media to your itunes/iphoto library, but if we were implementing the same workflow with CO it would just be moving from one group (Downloads) to another (a media library). Personally I like how this action creates a copy on OS X - that way I can do things like - delete the source file after importing - for a downloaded album, save the ZIP file it came in on an external drive for archival purposes, delete the extracted files, and maybe edit the metadata on the copy in my itunes library. > If I have photos in a library and I place them into documents, I expect the > changes I made on the photos with the Photo Manager or a Photo Editor to be > reflected in all the documents where I placed them. As a special case, when I > want a copy/snapshot, I would press the option key on a drop to get a copy > inserted (or click a checkbox if the photo insertion goes through a dialog). Hm... well I'd vote for doing a copy by default in that case, and requiring cmd+option for creating the alias. >> One potential problem is if we have multiple libraries containing composite >> documents containing images, and maybe we want the images to be copied if >> they're moved to a different document. > > Yes, but I doubt that's the behavior you want or expect by default. I'm not sure - copy would be the default behaviour for a Mac app following the HIG. (table 9-1 says dragging data in a document to another document creates a copy) >> The original design I was using for ObjectMerging with no notion of >> persistent root / embedded object would be able to handle this, by using an >> algorithm like: >> 1. find the closest parent of the drag source which is a document >> 2. find the closest parent of the drag destination which is a document >> 3. if the documents found in 1) and 2) are the same, link, otherwise, copy. > > If compound documents don't share objects automatically, but you have to > request it, that seems to defeat a bit the compound document notion which > revolves around implicit sharing between several compound documents. > Nobody has ever used a system based on compound documents in the real world, > so it's hard to say implicit sharing is a right answer… but still I'm tempted > to say so ;-) > > Either behaviors is easy to implement, even switching between both at runtime > shouldn't be hard, so I wouldn't worry about it. > It also seems introducing a root object notion doesn't impact the algorithm > you propose. Heh, yeah, I agree I'm worrying too much about this right now. ;-) We just need to get a demo running and test it. :-) >> On a semi-related topic, I think it should be possible to make deep copies >> in CoreObject really cheap - even if there are multiple GB's of >> image/video/music data inside the objects - we just need to make sure to >> share the attached files. > > > Would be a good :-) > > I'd say that cheap copies and branches seem to be one and the same. iirc we > discussed the idea to have no branch notion at the low-level but rather > copies tagged as branches… > I don't remember clearly, but some ObjectMerging version might even already > implement that. Haha, I forgot. But yeah, cheap copies and branches are pretty much the same. Cheers, Eric _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
