Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Using URL path on filesystem ? #7

Closed
dqueffeulouatw opened this Issue · 8 comments

5 participants

@dqueffeulouatw

I'm facing the following problem : it seems that when you have a path like /AAA/BBB , you cannot have a path like /AAA/BBB/CCC because the cache creates a file for /AAA/BBB, and can't create a directory for /AAA/BBB at the same place.

creating directory /var/mobile/Applications/B9710FFC-F486-4B2B-AACF-171023D323B8/Library/Caches/urlcachestore/mydomain.com/cam
created file at path /var/mobile/Applications/B9710FFC-F486-4B2B-AACF-171023D323B8/Library/Caches/urlcachestore/mydomain.com/cam/carrousel (5)

then (a log I added in createFileForItem:) on createDirectoryAtPath: :

ERROR Error Domain=NSCocoaErrorDomain Code=512 "The operation couldn’t be completed. (Cocoa error 512.)" UserInfo=0x105950 {NSFilePath=/var/mobile/Applications/B9710FFC-F486-4B2B-AACF-171023D323B8/Library/Caches/urlcachestore/mydomain.com/cam/carrousel, NSUnderlyingError=0x126500 "The operation couldn’t be completed. Not a directory"} creating directory /var/mobile/Applications/B9710FFC-F486-4B2B-AACF-171023D323B8/Library/Caches/urlcachestore/mydomain.com/cam/carrousel/carrousel

So I'm wondering if the file system is a good cache storage system when you have to create the URL path on it. That seems a bit difficult.

@artifacts
Owner

Good point. In the first versions of AFCache, I used a hash value for creating files but that was ugly to debug.
But I also encountered problems with long URLs when filenames have more than 255 characters.
I was thinking about CoreData, but I

  • don't want to force the developer to have a dependency to CoreData
  • think that the file system might be better for binary files (I'm not sure about that)

Otherwise CoreData might be a good idea because it would replace the serialized metadata dictionaries.

Any suggestions?

@dqueffeulouatw

Maybe you should look at what is done in EHCache (java).
It seems to have an index file and a data file.
The index file stores the key/address of each cache element. You have the key from the URL and get the address in the data file so you can retrieve the data in the data file.
Actually I don't known how to manage the data file and what the address is. Obviously, you don't have to load the data in memory.

Another solution could use an index file that stores key/hash and you name your files with the hash so you have separate files and fixed filenames.

@haikusw

agreed on not using core data

@bgalbs

We should look at how open-source browser caches handle this, like Mozilla or Chrome, as it is fundamentally the same problem space.

In the short-term, I'd settle for (a) comparing the serialization rules for iOS files versus URLs and make sure the two are compatible and (b) coming up with a scheme whereby:

AAA/BBB

is stored in the FS as:

AAA/BBB/(default resource)

or something like that.

@artifacts
Owner

we are currently porting afcache to android where we are using GUIDs for filenames and a directory structure based on parts of the guids. That seems to work well. When finished, we will implement it the same way on iOS.

@Rjvs

Did this ever happen? BTW, did you publish the Android port?

@artifacts
Owner

It's done in the URLProtocol branch, which is the main branch we're working on with our projects at the moment. We're testing the branch for stability and bugs in real world projects now and will eventually merge it into the master. The android port will be published soon, but we still have to clarify some legal issues, since the port was part of a client project.

@artifacts
Owner

merged into develop by now

@artifacts artifacts closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.