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

Using Extended File Attributes to Store Cache Record's Header #64

Open
sgl0v opened this issue Apr 12, 2016 · 8 comments
Open

Using Extended File Attributes to Store Cache Record's Header #64

sgl0v opened this issue Apr 12, 2016 · 8 comments

Comments

@sgl0v
Copy link

sgl0v commented Apr 12, 2016

Did you consider using Extended File Attributes to store a cache record's header (SPTPersistentCacheRecordHeader struct) ? Looks like this approach should simplify the headers management a bit.

@ChocoChipset
Copy link
Contributor

Interesting idea,

This would also allow files to be shared or inspected just like any other file using Finder or Preview, etc.

If nobody objects, this could be a good idea for a PR. Interested, @sgl0v?

@ChocoChipset ChocoChipset changed the title Extended File Attributes Using Extended File Attributes to Store Cache Record's Header Apr 13, 2016
@sgl0v
Copy link
Author

sgl0v commented Apr 13, 2016

@iOSCowboy , I'll start working on this if there are not objections. I would be nice to have a backward compatible solution I guess.

@ChocoChipset
Copy link
Contributor

Let's ping the gang and see what are their thoughts about it. Summoning @spotify/objc-dev!

Regarding backward compatibility: the life of the files in the cache is short lived, might be enough just to flush the cache at the beginning (just brainstorming, but I think the solution is something fairly simple).

Thanks for your interest, Max!

@dflems
Copy link
Contributor

dflems commented Apr 13, 2016

As far as backwards compatibility goes, we could have a "cache protocol version" that factors into the cache key. We bump that version whenever serialization changes in a breakable way and forces the cache keys to be different. And/or we store the serialization version for the cache ID in NSUserDefaults (or something like that) and if the version ever changes, we invalidate the entire cache. A solid migration strategy is something we should figure out otherwise we're locked in.

@8W9aG
Copy link
Contributor

8W9aG commented Apr 13, 2016

We originally didn't do this because we were considering making the cache in C with a small Objective-C wrapper on top, making a major use case to support POSIX systems. Having said that, thats not the way it panned out, and so I think it's perfectly acceptable to add extended file attributes to the cache for the metadata. Backwards compatibility unfortunately will be required, we have some offlined files using the persist mode, and it would be a shame if we nuked them for our users

@dflems
Copy link
Contributor

dflems commented Apr 13, 2016

@8W9aG: Many filesystems support extended file attributes (wiki). Would probably be more trouble than it's worth to cleanly support all of them, but it is possible to make a cross-platform core provided the FS supports extended file attributes.

@ChocoChipset
Copy link
Contributor

Thanks for the input, team.

Looks like this would be an awesome PR, @sgl0v!

@sgl0v
Copy link
Author

sgl0v commented Apr 13, 2016

Thanks for clarification, guys. Will start working on this improvement then.

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

No branches or pull requests

4 participants