I just tried the File API, which I think is pretty awesome.
I could imagine however, that if we use this API frequently to transfer files between nodes it would quickly increase the data size in each node.
- Is there any way to delete the uploaded file(s)?
- Do you have any general advice on how to use this API (e.g. for what purpose, file size limits, is it better that the file be ephemeral or permanent, etc)
thanks for trying it out! Adding proper support to the SDK and documentation on the website is what I plan on doing next week, and your questions help — they also make a lot of sense.
To answer the data management part: each node will retrieve and locally store the documents that apps request from it, and it will also store the documents to which you give a name. When disk storage reaches the configured limit (settings
/swarm/blockCacheSize and -count), garbage collection will delete files that are not accessible via a name until the configured limit is met again. So if you name many documents or store lots of events, your disk usage will at some point exceed the configured limit, but until then, excess capacity will be used to cache files.
In other words, deleting a file is done indirectly by removing its name.
In theory there are no limits to file sizes, you can store whole directories if you want. In practice the configuration and the disk size will impose limits.
I see. That makes a lot of sense.
About the naming, I saw in the docs that it uses the ANS, but I was not able to find out how to do that.
And I suppose removing a name should be done also through that mechanism, is my understanding correct?
Oh and I just also realized that the docs shows two different endpoints for retrieving using file name:
do both of them work? (I cannot check it since I don’t know how to attach a name yet…)
yes, your interpretation is correct that both URLs work for retrieving a file by assigned name. I have updated the docs to include information on how to attach names, please let me know if this is clear enough. There’s also an example on how to use this mechanism for serving a (trivial) website at the bottom — we’re experimenting with the term “conservative web app” for this approach (since you don’t need to do anything special like service workers).