Le 27 oct. 2010 à 17:00, David Chisnall a écrit : > On 27 Oct 2010, at 14:17, Quentin Mathé wrote: > >> Le 27 oct. 2010 à 11:50, Niels Grewe a écrit : >> >>> * Overhaul the binary backend: Presently it stores data in a >>> machine-dependent format, but it really should encode stuff in an >>> independent format. >> >> Would be better. > > I intentionally didn't do this initially, because the binary back end was > intended to be a fast local store. Portability was not an issue, because it > was never intended that you should move binary stores between machines. The > XML store was designed to be portable.
Right, I forgot about this point. > That said, I would quite like to see a ZFS-style approach, where the binary > store still writes in the native machine's format, but documents what this > format is so that binary stores can be read fast on the local machine or more > slowly on other architectures. Could be nice indeed. >>> * Reconsider the relationship with CoreObject: I'm curious to see >>> whether we can somehow integrate the automatic persistency from ES >>> with Eric's new more informed approach to versioning/merging. (e.g. >>> how does it relate to branches/versions in ES object stores?) >> >> 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. > > Sounds sensible. ok. >>> Since we probably don't want to break the format ES uses very often, I'd >>> be really interested to hear your opinions on the matter (questions? >>> further suggestions? issues?) >> >> 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. > > Yup, I think we can break it now, and as long as we add a version field > somewhere we don't have to worry too much about it in the future. > > By the way, I think we should never care about backwards compatibility for > the stores - a new ES/CO (after this cleanup) should always be able to load > old stores, but I don't see any reason why we need to support the converse. Hm, what you describe here sounds like forward compatibility (reading new stores with a old ES/CO) rather than backward compatibility (reading old stores with a new ES/CO)? Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
