I noticed the inconsistent casing in readdir verus readFile, too (https://github.com/beakerbrowser/beaker/issues/571). I understand the choice to use the Node.js fs module as a model at the time, but now Mozilla and others have published a spec for in-browser filesystem access as part of the libdweb project.
At first glance it seems to be a more consistently designed API. Plus, it might make a natural fit for Dat to fit in if other browsers are already looking at adopting the FileSystem API.
Yeah this is a good thing to look into. We aren't afraid to deprecate APIs. We can do things like leave the old API for a time, and even put out new APIs by names like DatArchive2. We just want it to be well-warranted, and this is the kind of thing that might warrant it.
Let's see what adoption turns into with the new filesystem APIs.
Most helpful comment
Yeah this is a good thing to look into. We aren't afraid to deprecate APIs. We can do things like leave the old API for a time, and even put out new APIs by names like
DatArchive2. We just want it to be well-warranted, and this is the kind of thing that might warrant it.Let's see what adoption turns into with the new filesystem APIs.