Using URL path on filesystem ? #7

Closed
dqueffeulouatw opened this Issue Jul 11, 2011 · 8 comments

Comments

Projects
None yet
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

This comment has been minimized.

Show comment Hide comment
@artifacts

artifacts Jul 11, 2011

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?

Owner

artifacts commented Jul 11, 2011

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

This comment has been minimized.

Show comment Hide comment
@dqueffeulouatw

dqueffeulouatw Jul 11, 2011

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.

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

This comment has been minimized.

Show comment Hide comment
@haikusw

haikusw Jul 12, 2011

agreed on not using core data

haikusw commented Jul 12, 2011

agreed on not using core data

@bgalbs

This comment has been minimized.

Show comment Hide comment
@bgalbs

bgalbs Sep 8, 2011

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.

bgalbs commented Sep 8, 2011

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

This comment has been minimized.

Show comment Hide comment
@artifacts

artifacts Sep 8, 2011

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.

Owner

artifacts commented Sep 8, 2011

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

This comment has been minimized.

Show comment Hide comment
@Rjvs

Rjvs Apr 14, 2012

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

Rjvs commented Apr 14, 2012

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

@artifacts

This comment has been minimized.

Show comment Hide comment
@artifacts

artifacts Apr 16, 2012

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.

Owner

artifacts commented Apr 16, 2012

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

This comment has been minimized.

Show comment Hide comment
@artifacts

artifacts Sep 26, 2014

Owner

merged into develop by now

Owner

artifacts commented Sep 26, 2014

merged into develop by now

@artifacts artifacts closed this Sep 26, 2014

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