mount local folder using files api ( recent browser ).

[trabitboy]

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

[benjamincburns]

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?

[trabitboy]

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 ) .

[trabitboy]

I was under the wrong assumption that the files apis was also able to write,
so I know understand better your comment about node.

[s-macke]

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.

[trabitboy]

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 .

[s-macke]

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.

[trabitboy]

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?

[s-macke]

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

[benjamincburns]

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).

[trabitboy]

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 ...