API tools faq
paste
Advertisement
Guest User

nacl proposal v1

a guest
Mar 24th, 2015
313
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 4.99 KB | None | 0 0
raw download clone embed print report
  1. Intro
  2.  
  3. Native Client introduced the nacl_io library, which allows developers to mount filesystems like html5fs and httpfs and access them using regular POSIX calls. At the moment, filesystem support is restricted to the local machine and to public http content using httpfs. The aim of this project is to extend nacl_io by adding new filesystems to it - specifically, cloud storage. Cloud is the future of computing, and letting developers mount a cloud storage as a regular filesystem would allow for more powerful Native Client applications in future.
  4.  
  5. Notes:
  6.  
  7. - Since the Pepper API provides classes for interacting with URL resources, my current focus in the project is to interface with HTTP based APIs. If time permits, JavaScript based APIs may be implemented.
  8.  
  9.  
  10. Project goals
  11.  
  12. - Expose at least one cloud storage( which uses HTTP based API) as a filesystem, starting with Dropbox.
  13.  
  14. - Implement local caching in the filesystem, so that files accessed from the cloud storage are available afterwards.
  15.  
  16. - Tests and demos for both of the above.
  17.  
  18.  
  19. Implementation
  20.  
  21. 1 Most cloud storage APIs support OAuth verification. The assumption in the project is that the developer completes the verification, and passes the access token to the filesystem in the mount string parameter as follows:
  22.  
  23. mount("","/mount/target","cloudfs","","provider=dropbox,access_token=somedata")
  24.  
  25. 2 In the initializer function for cloudfs, the parameter string is parsed. Different provider classes will be available, and cloudfs instantiates an object depending on the provider. The access_token data is stored in the class itself. Any time cloudfs needs to interface with the server, it uses the provider object. The provider classes will interface with the cloud server, according to the API.
  26.  
  27. 3 cloudfs will keep an array of structures fileMap, where fileMap contains {fileName,access_time,modified_time}. Every file in the cache will have an entry in fileMap. The time fields can be populated using the metadata from the cloud server and the local time from the machine. Caching functions can use the time fields to various ways. This array can be written to the cache storage periodically or before unmounting, so that this data persists.
  28.  
  29. 4 An html5fs mount will be created at the same point(/mount/target), which will serve as the cache. All calls will first be routed to this cache system. If these calls fail due to absence in the cache, cloudfs will use the provider object to call the server. The returned file from the server is then written to the cache. This behavior will change depending on the function being implemented, but the general idea should remain the same.
  30.  
  31. 5 Any operation on a file should modify fileMap appropriately.
  32.  
  33. 6 The caching operation described here is rudimentary at best, and will not support differential caching or journaling. Depending on the results of the community bonding period, these ideas will be refined.
  34.  
  35.  
  36. Timeline and deliverables
  37.  
  38. Community bonding period
  39. - Get familiar with nacl_io library and how developers use it in production code.
  40. - Decide between using httpfs or Pepper objects(URLLoader etc) in the base filesystem. httpfs already implements a lot of http access methods, so leveraging them would be advantageous. Also, httpfs has a caching system which I'd like to investigate, if it can be extended further.
  41. - Refine the implementation of the base filesystem(the interface with the cloud storage) currently planned.
  42. - Research the different APIs for their specific methods, and plan ways to create interfaces for them.
  43. - Research about how to efficiently implement caching in a filesystem, and ways to introduce differential caching and delta patching if possible.
  44. - Create templates for the planned implementations.
  45. - Get familiar with the jsfs system, and plan an implementation to interface JavaScript APIs with the proposed filesystem.
  46.  
  47. Week 1,2,3
  48. - Create the cloudfs class and the base implementation for dropbox.
  49. - Testing the implementation
  50.  
  51. Week 4,5
  52. - Creating a demo for the created implementation
  53. - Buffer week for further testing and refining, if any
  54.  
  55. Mid term evaluation deliverables
  56. - cloudfs class
  57. - Implemention of the dropbox interface
  58. - Demo for the same
  59.  
  60. Week 6,7,8
  61. - Implementation of caching functions.
  62. - Testing of the implementation.
  63.  
  64. Week 9,10
  65. - Working demo for cloudfs, with dropbox as the provider.
  66.  
  67. Week 11,12 ( Tentative)
  68. - Implement more interfaces for other cloud storages.
  69. - Testing of the implementations.
  70.  
  71. Final deliverables
  72. - cloudfs class, with local caching implemented.
  73. - Interface implementation for dropbox.
  74. - (Tentative) Interface implementations for other cloud storages
  75.  
  76.  
  77. about me
  78.  
  79. My name is Mainak Gachhui, and I am currently studying in Manipal Institute of Technnology. I am passionate about technology, and very interested in contributing to open source software. I do not have any major open source contribution yet, but I hope to change that with this project and continue even further.
  80.  
  81. contact details
  82.  
  83. Email: mgachhui@gmail.com
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!