This sounds really good. Having replication and clustering will be really important as we move forward. It will let us do all kinds of scaling and load distribution, and even manage things like internal, in-development or draft datasets that get published to a public site when ready... lots of great possabilities.
> > What we're thinking is to take this one level further, and implement > persistence itself as a "host"; so even in a single-host setup, > persistence would be a discrete thing, This makes a lot of sense. Replication also indicates one path to bridging different networks or different network transport mechanisms. I.e. you can have two sitehosts that mirror each other, one which is accessible over VIP, and one which is accessible over some obscure shared memory or other communications system. > A version control branch corresponds to a "concrete site", by which I mean > the information about one site as seen by one host (as opposed to the > "full site", which is the most up-to-date version as seen by the whole We should probably come up with some specific names for these things. Like: Site = A collection of vobjects that live together in one conceptual set, and may all be accessed in the same way (e.g. over VIP talking to one internet host). Host or Server = A server program (E.g. omnivos) that holds some vobjects in a site (maybe the whole site) or one replication/mirror within a site that has several replications. Or "repository"? Site version? = A copy of a particular version from a site's vobjects' revision histories. This could be said to be a version 'derived' from the 'ancestor' site. [should avoid calling them parents/children, to avoid confusion with vobject structure.] Or is this what you mean by branch? ... etc. > > - type list > - child list > - payload, if any (eg properties) > - security capabilities - parent list? > > Version control: how it's stored Hmm, it seems the only thing that you need to "reason" about merging is textual property data. I think we should really never have any situation in which there's a "conflict", unless you as a user specifically command it to merge two divergent branches, then of course you are there to resolve conflicts. What would the downsides be to treating payload (e.g. property data) as atomic? We can do diffs in a "version history" UI to present it in a nicer way. > Revisions and transactions Sounds pretty good, not sure I understand all the issues with local objects doing commits. Any particular call chain would be building up a list of commits, that would be executed by the initial vobject that got the message before it returns from handling the message and sends any reply? Regarding transactions, is this something that could be saved for later, after the basic revision control is implemented,or does it have to be integrated now? > > Horizons > ======== > > Off the top of my head, I think we'd like to be able to set a horizon per > host, per type, and per vobject, in that order of precedence (vobject > overrides type). What if a vobject has two different types that specify a > horizon? Respect the first? The last? What is a horizon?? Reed _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
