Agree with Feross, sometimes you want files, not db entries. E.g. to rendezvous with other processes on filenames.

It strikes me as very odd that we have the webkit-prefixed Entries API under way without WebKit support.

What do Apple folks intend to support? If not support Entries API, then can we regroup and get everyone to favor one reasonably complete (and unprefixed) plan?

 

/be

 

On Wed, Oct 12, 2016 at 5:05 PM Feross Aboukhadijeh <feross@feross.org> wrote:

> Why don't you store the data in IndexedDB? It can store blobs.

> All of WebTorrent's requirements in this thread ("use disk not memory") appear to be met by IndexedDB.

 

This is true. I'll investigate IndexedDB for the described WebTorrent use case.

 

Still, I maintain that filesystem support on the web platform could be vastly better. No directory upload, no way to persistently read/write files on disk, no way to stream files to disk. These improvements would help with some less-common WebTorrent use cases.

 

 

Feross

Blog | WebTorrent | Study Notes

On Thu, Oct 6, 2016 at 6:50 AM, Domenic Denicola <d@domenic.me> wrote:

From: Olli Pettay [mailto:olli@pettay.fi]

> On 10/06/2016 07:21 AM, Feross Aboukhadijeh wrote:
>> The web really needs a proper filesystem to properly compete with
>> native apps. I'd love to make WebTorrent (https://webtorrent.io) use
>> the disk instead of in-memory storage, but there's no clear cross-browser solution. So, in the meantime, torrent data is stored in memory and lost when the user navigates to another page.
>
> Why don't you store the data in IndexedDB? It can store blobs.

Exactly this. All of WebTorrent's requirements in this thread ("use disk not memory") appear to be met by IndexedDB.