Storage provider should respect scope argument

[willscott]

Storage definition constructor allows the instantiating class to specify a desired scope of storage. The default storage provider class currently ignores this preference.

Definition: https://github.com/UWNetworksLab/freedom/blob/master/interface/storage.js#L13

[ryscheng]

Clarification. Do you expect a single storage provider to satisfy all scopes? or can errors be returned if the storage provider doesn't support a scope (like "SHARED")?

[willscott]

Seems like a user preference where the storage provider should endeavor to store with the persistence requested by the application.

This was as much a test of constructor arguments as a needed addition to the API.

On Thu, Mar 6, 2014 at 7:41 AM, Raymond Cheng notifications@github.comwrote:

Clarification. Do you expect a single storage provider to satisfy all scopes? or can errors be returned if the storage provider doesn't support a scope (like "SHARED")?

Reply to this email directly or view it on GitHubhttps://github.com/UWNetworksLab/freedom/issues/53#issuecomment-36900466 .

[ryscheng]

With an example. Say a module depends on both isolatedStorage and dhtStorage. Each of these storage providers are meant for a particular scope, and the construction of them should not require a scope parameter. They implicitly have a scope and the developer is aware of that when they depend on it. So the developer in the module directly constructs one of each and uses each for different purposes. So then the question is, if a developer is directly constructing a specific provider implementation, how can a user hotswap?

On Thu, Mar 6, 2014 at 10:45 AM, Will notifications@github.com wrote:

Seems like a user preference where the storage provider should endeavor to store with the persistence requested by the application.

This was as much a test of constructor arguments as a needed addition to the API.

On Thu, Mar 6, 2014 at 7:41 AM, Raymond Cheng <notifications@github.com

wrote:

Clarification. Do you expect a single storage provider to satisfy all scopes? or can errors be returned if the storage provider doesn't support a scope (like "SHARED")?

Reply to this email directly or view it on GitHub< https://github.com/UWNetworksLab/freedom/issues/53#issuecomment-36900466>

.

— Reply to this email directly or view it on GitHubhttps://github.com/UWNetworksLab/freedom/issues/53#issuecomment-36900941 .

[willscott]

This is the same conversation we've had for the last year, right?

I don't know whether we're willing to say that the URL in the dependency is a 'hard link', or rather a hint at the implementation the developer would like to see used. If the user want to use Dropbox, or 'service x based' storage, and the developer hasn't thought to include a dependency to 'module for service x storage', how does that happen? Having a sense of scopes to know what is meant to be stored in a level that service can provide will let us do better than just co-opting all storage dependencies blindly.

--Will

On Thu, Mar 6, 2014 at 7:53 AM, Raymond Cheng notifications@github.comwrote:

With an example. Say a module depends on both isolatedStorage and dhtStorage. Each of these storage providers are meant for a particular scope, and the construction of them should not require a scope parameter. They implicitly have a scope and the developer is aware of that when they depend on it. So the developer in the module directly constructs one of each and uses each for different purposes. So then the question is, if a developer is directly constructing a specific provider implementation, how can a user hotswap?

On Thu, Mar 6, 2014 at 10:45 AM, Will notifications@github.com wrote:

Seems like a user preference where the storage provider should endeavor to store with the persistence requested by the application.

This was as much a test of constructor arguments as a needed addition to the API.

On Thu, Mar 6, 2014 at 7:41 AM, Raymond Cheng <notifications@github.com

wrote:

Clarification. Do you expect a single storage provider to satisfy all scopes? or can errors be returned if the storage provider doesn't support a scope (like "SHARED")?

Reply to this email directly or view it on GitHub< https://github.com/UWNetworksLab/freedom/issues/53#issuecomment-36900466>

.

Reply to this email directly or view it on GitHub< https://github.com/UWNetworksLab/freedom/issues/53#issuecomment-36900941> .

Reply to this email directly or view it on GitHubhttps://github.com/UWNetworksLab/freedom/issues/53#issuecomment-36901866 .

[ryscheng]

I think this is a different question than what we've talked about in the past. My main question is are we sure that passing in a scope into the constructor of the storage provider is the right way to indicate to the developer what the scope is? Whats the point of that? What does it mean to have the provider respect the scope? Aren't there more axes that a storage provider can vary? In distributed storage, are you requiring coherence? consistency?

e.g. dependencies: { globalStorage: {url: "...", api: "storage"} }

The app developer then uses globalStorage and needs some way to convey to the user that the application expects this provider to be a global namespace across all users with sequential consistency. So you can replace it with anything with sequential consistency, but something with eventual consistency (or localStorage) may break intended behavior.

Does the interface enforce that? Does the construction check for that? Or is there even a point to putting it in code?

On Thu, Mar 6, 2014 at 10:59 AM, Will notifications@github.com wrote:

This is the same conversation we've had for the last year, right?

I don't know whether we're willing to say that the URL in the dependency is a 'hard link', or rather a hint at the implementation the developer would like to see used. If the user want to use Dropbox, or 'service x based' storage, and the developer hasn't thought to include a dependency to 'module for service x storage', how does that happen? Having a sense of scopes to know what is meant to be stored in a level that service can provide will let us do better than just co-opting all storage dependencies blindly.

--Will

On Thu, Mar 6, 2014 at 7:53 AM, Raymond Cheng <notifications@github.com

wrote:

With an example. Say a module depends on both isolatedStorage and dhtStorage. Each of these storage providers are meant for a particular scope, and the construction of them should not require a scope parameter. They implicitly have a scope and the developer is aware of that when they depend on it. So the developer in the module directly constructs one of each and uses each for different purposes. So then the question is, if a developer is directly constructing a specific provider implementation, how can a user hotswap?

On Thu, Mar 6, 2014 at 10:45 AM, Will notifications@github.com wrote:

Seems like a user preference where the storage provider should endeavor to store with the persistence requested by the application.

This was as much a test of constructor arguments as a needed addition to the API.

On Thu, Mar 6, 2014 at 7:41 AM, Raymond Cheng < notifications@github.com

wrote:

Clarification. Do you expect a single storage provider to satisfy all scopes? or can errors be returned if the storage provider doesn't support a scope (like "SHARED")?

Reply to this email directly or view it on GitHub<

https://github.com/UWNetworksLab/freedom/issues/53#issuecomment-36900466>

.

Reply to this email directly or view it on GitHub< https://github.com/UWNetworksLab/freedom/issues/53#issuecomment-36900941

.

Reply to this email directly or view it on GitHub< https://github.com/UWNetworksLab/freedom/issues/53#issuecomment-36901866>

.

— Reply to this email directly or view it on GitHubhttps://github.com/UWNetworksLab/freedom/issues/53#issuecomment-36902522 .

[willscott]

I think this is exactly the same question, where we really don't know what the right way is for the app, user, and provider to interact.

'scope' was not intended to be the right answer, but rather: a. provide an example of constructor arguments. b. provide a strawman for us to think about what we want.

Coherence and consistency are good things to think about. I wonder though if those are things the average developer is going to want to have to decide themselves.

We could imagine a meta storage provider that chose an appropriate implementation based on what the user wants.

I'm not sure if the interface can enforce proper behavior of the providers, right?

[ryscheng]

I think the consensus is to remove SCOPE argument for storage constructor. If we want to keep a good example of where provider constructors are used, let's migrate our attention to: https://github.com/UWNetworksLab/freedom/issues/71