search

jvilk / BrowserFS

BrowserFS is an in-browser filesystem that emulates the Node JS filesystem API and supports storing and retrieving files from various backends.
Other
3.07k stars 218 forks source link

XmlHttpRequest Filesystem #25

Closed jvilk closed 11 years ago

jvilk commented 11 years ago

Add an XmlHttpRequest filesystem that grabs files from a server. To start, it will use a JSON-based index file that contains any relevant file properties (mainly: file size, whether or not it's a directory, and potentially permissions information).

I'm working on this now, as it's required for Doppio integration.

perimosocordiae commented 11 years ago

We should think about the listings.json object that this FS will require. It should be flexible enough to support a range of requirements: from just listing file and directory names, to including sizes, permissions, and mtimes.

Also, we should automatically detect when the file index is out of sync with the server by handling the case where a request for an indexed file returns 404.

It would also be nice to have support for a "no-listings" mode that assumes the presence of a standard index page for each directory, which builds the file index given only one or more root URLs.

perimosocordiae commented 11 years ago

As of commit e7824c8e72e6f80a58e6aae428b7e35e5c1574db, the XmlHttpRequest FS passes all tests on both Chrome and Safari.

jvilk commented 11 years ago

How did you set this up? I see you added a proxy line to the karma config on port 8000 -- did you have a second server serving up static/non-watched files, or is there a way to have Karma serve up static content?

perimosocordiae commented 11 years ago

Yep, just start a simple http server in the repo root.

jvilk commented 11 years ago

STATUS: Once I add the compatibility goodness to this FS, I can close this issue.

I need to inject VBScript for IE, and have non-arraybuffer downloads for browsers w/o arraybuffers.

jvilk commented 11 years ago

Fun note: IE (at least IE9; haven't tried 10 yet) doesn't support arbitrary UTF-16 localStorage data. Or maybe it actually verifies that it's a valid UTF-16 string... either way, I can't use the clever binary string trick for it. Gonna have to use a regular binary string or something.

perimosocordiae commented 11 years ago

See: http://stackoverflow.com/a/11173673/10601

jvilk commented 11 years ago

So Firefox and IE can't use our fun binary strings.

0x0000 is a NULL-byte, which truncates all following characters in IE.

$&#^ C strings.

perimosocordiae commented 11 years ago

So, we base64 encode IE data? The Firefox case is unfortunate... there are only about 2000 numbers we can't use, so base64 would be overkill.

jvilk commented 11 years ago

Well, we have some options.

Simplest:

Space efficient:

I'm going to go with choice 'A' for now.

int3 commented 11 years ago

I think FF's bug only affects its older versions -- the tests and the jsfiddle linked from the SO question seem to pass for me on FF 22 / OS X. So it's probably not that big a deal if BrowserFS falls back to an inefficient implementation for older FF.

jvilk commented 11 years ago

Awesome. I'll make sure to do feature detection on a character unsupported by those FF versions and IE before performing the fallback. Thanks for checking.

perimosocordiae commented 11 years ago

Bump. Is this resolved now?

jvilk commented 11 years ago

There are some IE9 issues, so I can't close this yet.

jvilk commented 11 years ago

I'm going to close this, since we already have an IE9 issue. And I think this is resolved now. :smile: