[narwhal] Filesystem A Draft 6

[Rob Dawson]

I've just started using Narwhal and Common JS for some file system
based scripting. In doing so I saw the current implementation doesn't
match the current version of the spec. In at least a couple of places
it seems to be method renaming (removeTree in the spec compared to
rmtree in narwhal). I'm wondering about plans to move narwhal
forward, and if it makes sense for me to jump in and make a couple of
changes. Do you have a strategy for deprecating methods? Anyway, I'm
keen to see the File module in narwhal brought forward, and I'm
willing to help make this happen.

Regards,

Rob

--
You received this message because you are subscribed to the Google Groups "Narwhal and Jack" group.
To post to this group, send email to narw...@googlegroups.com.
To unsubscribe from this group, send email to narwhaljs+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/narwhaljs?hl=en.

[Kris Kowal]

On Mon, May 24, 2010 at 2:21 PM, Rob Dawson <rob...@rojotek.com> wrote:
> I've just started using Narwhal and Common JS for some file system
> based scripting.  In doing so I saw the current implementation doesn't
> match the current version of the spec.  In at least a couple of places
> it seems to be method renaming (removeTree in the spec compared to
> rmtree in narwhal).  I'm wondering about plans to move narwhal
> forward, and if it makes sense for me to jump in and make a couple of
> changes.  Do you have a strategy for deprecating methods?  Anyway, I'm
> keen to see the File module in narwhal brought forward, and I'm
> willing to help make this happen.

The "file" module in "master" is an implementation of CommonJS
Filesystem API, Proposal A, Draft 4.

The "narwhal/fs" module in "future" is an implementation of the
Proposal A, Draft 6, and is written in pure JavaScript, assuming the
existence of an implementation of "fs-base".

There are several implementations of "fs-base" which conform to
Proposal A, Level 0. We have one for Rhino in "master", and one for
Node in the "narwhal-node" package. In my "migration" and "future"
branches, there are a variety of implementations, one of which is
built on top of "file" as a stopgap adapter. There's also an
implementation of "file" that is built on "fs-base".

The state of things with CommonJS is that "fs-base" is widely
implemented and effectively ratified. "file" is our de-facto standard
on Narwhal and we shouldn't make any changes to it. Since the latest
draft of the complete filesystem API isn't ratified either, I'm
keeping it in the "narwhal" namespace. If it is ratified as is, we
can just link it to "fs" or "common/fs". If the specification
undergoes further drafts (as it will very likely need to), we won't be
squatting on the top-level name space, which would make migration
difficult, much as our "file" module would have if the CommonJS
specification called for a module with the same name and a different
implementation.

Things are a little tricky about migration, but the short story is
that we have an implementation of FS/A Draft 6, it's called
"narwhal/fs". It is finished and should work anywhere that "fs-base"
has been implemented. We also have several implementations of
"fs-base" lying around. One of the implementations should work for
you, but I haven't verified every scenario.

You can find the implementation of "fs-base" that you're using by doing a:

print(require.loader.find("fs-base"));

Kris Kowal