jor1k
jor1k copied to clipboard
s-macke
mount local folder using files api ( recent browser ).
Uploading a file and downloading a tar.gz is cool, but being able to mount a local directory would be interesting . On browsers supporting the files api, it is technically possible. I have no idea how to program a linux fs from scratch, but as jor1k already has a js based filesystem, probably changing its backend to target files api doesn't seem too far fetched ?
motivated
If you go to work on this, perhaps you should consider writing it as a separate client-side npm module which translates 9p to the files API?
I'm a bit confused by the npm reference? I was thinking everything in browser ? ( my target is to get embedded linux to grep, process , local folders for instance, because I don't have the rights to install cygwin/exes ) Trying the html5 files api at the moment. I'll look into 9p ( I don't know anything on the inners of filesystems right now ) .
I was under the wrong assumption that the files apis was also able to write, so I know understand better your comment about node.
trabitboy, you are not the first who is suggesting it. It is possible and would be a nice feature. However when I read the red boxes on the websites like https://developer.mozilla.org/en-US/docs/Web/API/File_System_API http://www.html5rocks.com/en/tutorials/file/filesystem/
my motivation drops to zero implementing it. With "some browsers" you mean basically Chrome.
A implementation on the server side is of course possible. Actually my "cloud" backup button is already a tiny step in this direction.
Well actually I also have access to an old-ish chrome in this restricted environment, and I don't mind to investigate. Knowing js and c , and absolutely nothing on filesystems , it sounds kind of fun to hack a backend; I will probably have questions though .
You are free to do so. POSIX filesystems are not complicated. However, to support the current filesystem API, you have to modificate a lot of the current implementation. It begins with a message based interface to the main thread, because I think, that the filesystem API doesn't work in a worker thread.
Trying to look into "hacking" a hardcoded fs in the existing implementation to begin with; I was wondering what your development workflow was ?
I can run the "simple" demo locally in my browser, but I can't see or breakpoint the dynamically loaded js in either firefox or chrom or get easily debug messages from the worker thread. How do you work?
For debug messages I use the following code message.Debug("This is my string"); The debug message is sent to the main thread and is then printed via console.log
To stop the current emlation you can use the message.Abort() function
I was just suggesting writing an npm module because there's likely bits that are reusable. You can use npm as a package manager for client side code w/ request.js or browserify.
If you want to keep everything nice and modular and well encapsulated, you'll likely be writing a chunk of code which converts 9p messages to JS function calls, and then a separate module which registers a bunch of functions with that one, so that the 9p messages actually translate to something useful. The "9p to JS events" bit is ripe for being written as a reusable npm module. This could help @copy for instance, to reuse this code (should he want to).
Hi, I've been testing chrome local file api, but you can only write to a sand box, which I can't seem to find the location of, so usefulness is not very high ...