Announcing a new version of solid-file-client, a JavaScript library for reading and writing files and folders on Solid PODs.
Thanks to the very talented @linonetwo, solid-file-client has now moved into the twenty-first century. New features include:
tests
cleaner promise-based error trapping
babel compilation for ecmascript compatibility
builds that bundle rdflib and solid-auth-client
builds for node and ESM
now available with NPM
now available with jsdelivr CDN
See the README for details. There are a few relatively minor interface changes, so if you are already using solid-file-client, please check the changes.log.
Thanks to @linonetwo for sharing his knowledge of build flow, compilers, and
es6 goodies! He had to experiment to get rdflib and solid-auth-client into a bundle. If any of you want to do that with your apps, check out how he did it in solid-file-client.
Yes, solid-auth-client and rdflib are bundled in, so they’re still there but no need to call them explicitly, though you can if you want.
Sorry about the refactoring. The price of early adoption :-(. Main things to watch for in the refactor : the initial declaration no longer uses new SolidFileClient() and readFile() returns the file content as body, not body.value.
I am most of the way through refactoring solid-ide and it’s pretty straight-forward. Let me know if you run into any questions, I’m more than willing to help out.
I think we can move solid-auth-client and rdflib to peerDependencies and remove them from dependencies, so you can always bring your perferred version of them to override solid-file-client
My philosophy is make easy things easy and hard things possible. In other words - let it work out of the box with the tested versions and if someone wants different versions, they can add them on their own.
I don’t know if it is a Solid-file-client or a Solid-ide improvement, or may be both.
Working with TiddlyWiki connector to Solid pods I came to use 2 mime-types : .json and .tid
For .json there seem to be an issue with node-solid-server issue#1011
For .tid file I was unable to create any file with the Solid-UI green + button, so I create it with Solid-ide, but your app display the content as a default .ttl file.
I understand that as from now on .ttl extension is an obligation on node-solid-server (as from v5.00)
could you then default to mime-type text/plain.
The on-going use of Solid and the multiplication of mime-types would be easier.
Should the mime-type list be used in only in Solid-ide ?
I don’t know if your mime-type list relates to your apps, Solid-spec or the actual Solid-UI.
That’s why I do not report the issue to node-solid-server
The file type guessing is only used when going directly to a file rather than when reading the file from a folder list, in which case the type the server sends is used. And the file-type is only relevant to the syntax-highlighter. Since there is no tiddly-wiki plugin for the editor, there is no benefit to recognizing it. If solid-file-client defaults to “text/turtle” rather than “text/plain” the only difference is the syntax highlighting , which would be incorrect for tiddly-wiki anyway. So I am not seeing a resolvable problem. Am I missing something? What is the undesirable behavior that happens?
I don’t know tiddly-wiki but is it a flavor of markdown? If so, maybe you should use the “.markdown” extension since there is an editor plugin for markdown.
The cleanest approach for solid-file-client is, I think to always read the folder. In other words, you ask for file X and it first reads the folder file X is in, finds X’s file-type in the folder’s triples, and use that as it does in other circumstances. I may implement that in the future, though, as I say, the only impact is on the syntax-highlighter, so recognizing the file type of something the syntax-highlighter doesn’t recognize is fairly useless.
Something occurred to me. Perhaps you are talking about the situation in which you create a new file without specifying a content-type. In that case, it is the server that assigns a content-type based on the extension. I don’t touch that.
In solid-ide guessing relates only to the syntax highlighter so it really does not matter what it defaults to since if the file type has a highlighter, the script will know the extension and in most cases guessing is bypassed by reading the triples.
In solid-file-client guessing is only used in the readAndParse() method as a convenience - the user should specify the type if they care and if they don’t the safest choice is turtle since that is what readAndParse() mostly handles.
@jeffz, Superb, works a treat! I have a question, do you happen to know of any .js browser based libs to manage user/ group permissions on solid files and folders?
There is solid-acl for reading permissions. I don’t know of anything at the moment for writing permissions other than the rainbow menu in the databrowser. I have started some work on adding permissions to solid-file-client but nothing ready quite yet. Part of the issue is that it’s all in flux right now. The latest server (NSS 5.0) implements the part of the spec that says that both apps and users need to be authorized and that adds a layer of complexity to the issue.
,
