Stores need to be aware if they are responsible for hosting data on a domain or not

[joepio]

When a Commit is being made to a store (when data is changed), this store will need to know if this Commit has to be stored locally, or if it has to be sent to some external server.

I think the primary concern should be getting the names of these concepts really clear. Some of the terms I'm currently using or considering:

• Base URL
• Server
• Pod
• Companion server
• Target store

Maybe this can be resolved by simply adding a self_url property for servers.

Perhaps related: it might be a good idea to refactor store.set_default_agent, Agent and Config. Config overlaps heavily with Agent.

[joepio]

In atomic-cli, I've implemented logic to deal with who's the current Agent, and where the Server is located which should be writed to. However, I think this kind of logic (dealing with who's the agent and where the server is located) should sit in Store, and be tucked away as much as possible. Store should know the default Agent and the Server's address. This should prevent explicitly passing things like the Agent's private key, the server's URL and more to all sorts of functions.

[joepio]

Resource.save() is one of the methods that needs to know: 'should I post this commit, before I apply it locally, or am I the source of truth?'

[joepio]

I've ran into an issue with this. The client used get_base_url to determine if a resource should be present. This made sense in the server, but not in the client. I ended up adding a get_self_url function, which returns Option<url>. Currently, only DB returns a value, since that is used in server. Not sure how this should work in the end, I'm not quite happy with the current state, but it works.

[joepio]

Also had to add save_locally (especially for quick tests)