Closed dqueffeulouatw closed 10 years ago
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
Otherwise CoreData might be a good idea because it would replace the serialized metadata dictionaries.
Any suggestions?
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.
agreed on not using core data
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.
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.
Did this ever happen? BTW, did you publish the Android port?
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.
merged into develop by now
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.