Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to specify Pantry file location #32

Open
cjwirth opened this issue Feb 10, 2016 · 7 comments
Open

Ability to specify Pantry file location #32

cjwirth opened this issue Feb 10, 2016 · 7 comments

Comments

@cjwirth
Copy link

cjwirth commented Feb 10, 2016

I think it would be kind of nice to be able to save to different locations.
Right now, it saves in the Caches directory, but maybe we could also save to the Documents directory for example.

I was envisioning something maybe like

public class Pantry {    
    public init(warehouse: Warehouseable) { }
}

You could keep the static methods around, referencing some shared instance.

Something would have to be done about enableInMemoryModeWithIdentifier . Maybe you could change it to some shared warehouse instead?

public static func setDefaultWarehouse(warehouse: Warehouseable)

It looks like everything in Pantry is static, so I understand it wouldn't be the most trivial change. I don't mind looking into some of these changes, but I thought I'd ask what you thought about it first?

@tsheaff
Copy link
Contributor

tsheaff commented Jun 16, 2016

I agree this would be nice. In fact, feels like the default should be Documents directory, not caches. I'm planning to use this to store reasonably critical params that are user-chosen and thus not re-generatable, but apple docs say this about the Caches directory:

"Generally speaking, the application does not require cache data to operate properly, but it can use cache data to improve performance. Examples of cache data include (but are not limited to) database cache files and transient, downloadable content. Note that the system may delete the Caches/ directory to free up disk space, so your app must be able to re-create or download these files as needed."

@henrinormak
Copy link

As it would be sort of mutually exclusive with the enableInMemoryModeWithIdentifier, would it perhaps make sense to move all of this logic to an enum? Basically allow switching Pantry between in-memory, Caches dir, Docs dir and a custom directory. I wouldn't mind contributing, as I would like to share some basic data as a file between an iOS app and an extension, which Pantry would be perfect for.

@nickoneill
Copy link
Owner

We'll be moving this away from caches. This should be 100% documents directory as far as I'm concerned.

Does that work for sharing between apps and extensions @henrinormak or do we need the ability to specify a custom directory as well?

@henrinormak
Copy link

Not really, as far as I understand, shared files are located in a separate directory outside of the app sandbox. This shared location is accessible by both the app and the extension, but neither really "owns" it as part of their own sandbox

@nickoneill
Copy link
Owner

That's fine @henrinormak, providing a customizable directory is not a problem. I'm not sure in-memory is useful at all for actual use cases (it's provided right now for the tests). Upon reviewing the options we have... Application Support actually fits better than Documents.

@henrinormak
Copy link

Right, assuming we leave the nitty gritty of which directory is used by default (it seems like for extensions this particular API is the way to go) aside, is someone currently working on something like this? I mean supporting the change of directory? I wouldn't mind investing some time into this, but I wouldn't want to duplicate work if someone has already started.

@nickoneill
Copy link
Owner

I don't believe it's being currently worked on. Swapping the storage directory should be pretty trivial though, it's computed in a single location IIRC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants