Hi Quentin, On Wed, Oct 27, 2010 at 03:17:19PM +0200, Quentin Mathé wrote: > I have started reworking the object store API to regroup delta and full saves > into single unit/store rather than using two object stores. > I need to finish this code and commit it. Should I finish this asap or is > this not too critical? > We can discuss thereworked API and the needs you envision in more details if > needed… > I have some other ES API and code cleaning changes still to be committed. Let > me know if you prefer I commit that asap or later (after you merge your > recent work into trunk).
Most of the archiver/unarchiver stuff lives in its own file, with only a few support changes in ETSerializer.m and ETDeserializer.m, so feel free to commit your changes whenever you're ready. I don't mind taking time to adapt my stuff for them. > I also plan to add an Info.plist (or equivalent) to store some ES/CO > internal informations/metadatas in each object store. Would also > enable to recover the core object graph in case the metadata db gets > corrupted. That sounds excellent. > Afaik, there is no branch concept in Eric's CoreObject and each version is > uniquely identified by a SHA. Uniquely identified version makes much easier > to handle merging. You can freely move around bits of history. For example, > suppose you copy some history to another core object, makes some more changes > and then wants to reintegrate it back into the first core object. You could > also compute which parts of the history can be deleted more easily (the job > of the garbage collector to be written). > > We discussed the matter a bit with Eric last string and I told him I liked > the ideas and suggested we could keep the same ES API (or not), but decide > that: > - a branch is just a convention at the implementation level (a core object > directory inside another core object directory in the case of an object > bundle, and a reference to the "parent" version and core object) > - identify each core object version by a UUID on disk (and cache a version > number in the metadata db or put both in the archive filename) > > My opinion is that branches should probably not exist at the implementation > level but are a convenient construct at the API and user level. So the consensus is that ES should only provide persistency services and CO is exclusively in charge of tracking object history etc.? Sounds fine to me. > As I said, I think it doesn't matter to break ES format for now, > although we should think about a backward compatibility mechanism. > Just put a big warning in each commit that breaks the format and tells > people they need to delete their CoreObject library. Fine. So I'll happily break stuff whenever I need to :-) Cheers, Niels _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
