Single instance cloud storage for home-brewed realms?

[EightBitz]

Not sure if I'm using that term correctly, but this is a question for Rob or another developer.

It's been mentioned before that an individual's cloud account will not contain the data for purchased content so much as it'll have pointers to it. This is what I mean by single instance storage. The data is stored in the cloud once, and anyone who has that data associated with their account will only have pointers.

Will duplicated home-brewed realms work the same way? If I create Realm X.1, and I create a copy called Realm X.2, will that take up twice the storage, or will Realm X.2 have pointers to the data in Realm X.1?

And if the answer is pointers, what happens when I start making changes? Will it keep pointers for unchanged data and store data for the delta, or will it create a full copy of the realm to accommodate storage of those changes?

 

[Zaphod Beebledoc]

I do hope I don't get ninja'd by the boss again, but...

Will duplicated home-brewed realms work the same way? If I create Realm X.1, and I create a copy called Realm X.2, will that take up twice the storage, or will Realm X.2 have pointers to the data in Realm X.1?

I think Realm X.2 will have pointers to the data.

And if the answer is pointers, what happens when I start making changes? Will it keep pointers for unchanged data and store data for the delta, or will it create a full copy of the realm to accommodate storage of those changes?

And there I do believe that keep the pointers for unchanged data and store data for the delta.

Hope I'm right!

 

[mirtos]

See I would assume the opposite. Especially consider deletes (which we know are eventually coming). The user would have to be told which realm is the "primary" so if they changed or deleted the primary it wouldnt auto change or delete the copies.

It would also make things very confisuing if you made changes in the primary and copies. deltas alone can get confusing with two way changes.

Example:

I have a realm called "Realm" (originally huh?)
in it I have a city called "City".

I then copy realm into realm.2

In Realm.2 I make changes to city, and thats a "delta"..
But in the original "Realm" I then make changes to City, seperate from the snippet that was changed in Realm.2.. what does the city in Realm.2 look like? Is it overritten when i make changes to the primary, does it try to do a diff? merge them?

 

[Zaphod Beebledoc]

I do believe that to copy a Realm you put into the Repository then grab a copy of that. (Which to start with would just be pointers...) So if you then make a change to the copy on your machine, it wouldn't affect the repository version.

Does get me thinking though about what do you do if you upload to the Repository then some time later want to make a few changes... will you be able to change it?

 

[Mystic Lemur]

If you make changes to imported content, it's supposed to become your own copy. So, changing the original should not affect what you've changed in your realm. I do hope that downloading "updates" to imported realms is optional. I'd hate to know that one person could add something to his realm and the 1000+ people who he has shared it with have no choice but to accept his changes.

 

[Silveras]

If I recall correctly, there was passing mention of being able to accept or reject changes in some fashion.

I presume that will be discussed in more detail as the Marketplace and Repository get closer to release.

 

[Zaphod Beebledoc]

I presume that will be discussed in more detail as the Marketplace and Repository get closer to release.

Now, I think I might be rollings these up and mixed into one! I think I'll continue to use liberal amounts of "I think" in posts until I know better...

 

[rob]

I'm going to user the terms "master realm" and "derived realm" to refer to the original realm and the one that is a "copy" of the original, respectively.

First of all, the whole "master" and "derived" mechanism will be essentially (although not exactly) the same for sharing material with others and sharing material with yourself. They will be conceptually the same to keep things simple for everyone.

When the "derived" realm is created, it will consist of a whole bunch of references to the "master" realm. For the technical folks, you can call them "pointers", since that's more familiar terminology, but I'm trying to make this understandable by the non-techies out there as well.

When you add new content to the "derived" realm, that new content is created as part of the "derived" realm. When you modify content within the "derived" realm, the reference to the "master" is abandoned for that content and the modified data is stored as part of the "derived" realm. When you delete content from the "derived" realm, the reference to the "master" is deleted so that it's gone from the "derived" realm.

When you add new content to the "master" realm, it will be flagged as available to the "derived" realm. Similarly, any changes or deletions to the "master" realm will be flagged as available to the "derived" realm. Any changes that conflict with changes to the "derived" realm are fundamentally lost to the "derived" realm. For example, changes to something in the "master" that was deleted in the "derived" realm are lost. Changes made to the "master" that were changed in the "derived" realm need to be flagged, just in case the user "corrected" something in the "derived" realm that was subsequently corrected properly in the "master" realm.

At this point, users will need to either accept the changes made to the "master" into the "derived" realm or reject those changes. Initially, the expectation is that these changes will be an "all or nothing" proposition, but the plan is to make things more granular in the future so that individual changes can be accepted or rejected. Allowing control at the individual change level will entail a LOT more work within the interface, plus it will potentially be very fiddly for users, so users will generally just adopt an "all or nothing" behavior, even if the detailed control is available. That's why we're not going to worry about adding it initially.

That's the plan for how things will work. It's relatively simple for users, but there's a lot of of complexity under the covers to orchestrate everything properly.

I hope this is sufficient detail, since I don't plan to delve into the details further than this right now - I need to get back to work on everything that's on my plate. This ought to give everyone a very solid idea of how it will all work.

 

[Viking2054]

Will we be able to review and compare the possible changes before we are forced to click the accept changes or reject changes button?

If I initially reject the changes, will I be able to accept the changes later on if I wish?