Browser compatibility

[multimeric]

Currently it seems that Crate-O uses window.showDirectoryPicker which I think relies on the File System Access API. As you note in the readme, this only works on Chrome currently.

I'm wondering if you could additionally support the File and Directory Entries API
which is fully supported in all modern browsers, and still lets you list files, with the small downside that users have to drag-and-drop them into the application. For example you can use the .webkitGetAsEntry() method. Here is an example of recursively listing the contents of a directory using this API: https://codepen.io/Migwell/pen/VwJJvRm.

I have read this note:

We will be releasing a version that can be deployed as part of a service that accesses online resources directly, which will be compatible with other browsers (see the Roadmap).

However the roadmap doesn't seem to mention this feature. Also, working with local resources in non-Chrome browsers is still desirable.

[moisbo]

Thanks Michael. When we started this implementation of crate-o I dont remember if it was fully compatible. However it might be a no-no to have people drag their whole dataset drag-and-droped to the browser. Does that mean files are stored in memory?

This version of Crate-O, the one published in github pages is an implementation of the Vue component. We have implemented the component in other apps. We have one example https://ro-crate.ldaca.edu.au which uses a backend for storing files. See https://github.com/Language-Research-Technology/crate-o/blob/main/docs/component.md for implementing the component in your own app as well, which would be compatible with any browser as you can see in the example link.

[multimeric]

However it might be a no-no to have people drag their whole dataset drag-and-droped to the browser. Does that mean files are stored in memory?

No, I'm fairly sure it doesn't read any files unless you use the .file() method on a given file.

We have implemented the component in other apps. We have one example https://ro-crate.ldaca.edu.au/ which uses a backend for storing files.

Thanks for the info. For my use case, I think it's actually preferable to be a client-only app. This means we don't have to deal with provisioning servers etc.

See https://github.com/Language-Research-Technology/crate-o/blob/main/docs/component.md for implementing the component in your own app as well, which would be compatible with any browser as you can see in the example link.

Does this decouple the data loading from the editor? If so, I could indeed implement the API I mention above in my own app. However, I think I would prefer to push this feature upstream if you guys are interested.

For what it's worth I'm happy to implement this feature, I don't think it would be too challenging, though I would have to see.

[moisbo]

Does this decouple the data loading from the editor? If so, I could indeed implement the API I mention above in my own app. However, I think I would prefer to push this feature upstream if you guys are interested.

Yes! also please if you are happy with this we can merge the new implementation into this app (as a PR) if its better and compatible with more browsers! very welcomed!

[multimeric]

On a related note, I think it would also be useful to be able to describe a dataset in the abstract, without Crate-O actually seeing the filesystem. This would make the tool usable without any filesystem APIs, although it would require users to ensure they choose correct file names.