lib/File.js

[Ben Taber]

Playing around with writing/creating/reading files. Started with the
posix documentation, but then noticed that there is a thin wrapper
around the posix functionality in lib/file.js. It seems only
partially implemented, and perhaps an afterthought, especially
considering it doesn't show up in the documentation.

Are there plans to expand this module, or should I go ahead and make
my own abstraction?

Thanks,
Ben

[Tim Caswell]

What kind of functionality are you looking for?  I had written a file class for Ryan and as far as I can tell the one in file.js is based on my code.  But to tell the truth, all I ever use are the read and write static methods in the file module.

I think once we settle on the new promise api, then we can design a much easier to use file class.

There is one abstraction in my node branch that allows for using strings like "r", "w", "a+",  etc... instead of mixing all the low-level option flags (process.O_WRONLY | process.O_TRUNC | process.O_CREAT | etc...). I feel that this makes the posix module much easier.

[Felix Geisendörfer]

> It seems only
> partially implemented, and perhaps an afterthought, especially

Why do you think its incomplete? I've been using it for reading/
writing files quite a few times in the past.

> considering it doesn't show up in the documentation.

Unless Ryan is unhappy with the current API, I think thats just a
matter of submitting a patch for the docs. Ryan: Would you like to
keep the current API and get it documented?

--fg

> > --
>
> > You received this message because you are subscribed to the Google Groups "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.

[Ryan Dahl]

2010/1/1 Felix Geisendörfer <fe...@debuggable.com>:

> Unless Ryan is unhappy with the current API, I think thats just a
> matter of submitting a patch for the docs. Ryan: Would you like to
> keep the current API and get it documented?

Not sure yet. I'm thinking about having some simpler API for dealing
reading or writing a file as a stream, but perhaps not both. I maybe
just left people use the low-level API if they're not only reading or
only writing...

[inimino]

Ryan Dahl wrote:
> 2010/1/1 Felix Geisendörfer <fe...@debuggable.com>:
>> Unless Ryan is unhappy with the current API, I think thats just a
>> matter of submitting a patch for the docs. Ryan: Would you like to
>> keep the current API and get it documented?
>
> Not sure yet. I'm thinking about having some simpler API for dealing
> reading or writing a file as a stream, but perhaps not both.

I am writing something like this for streaming:

// streamFile :: (path::String, encoding::String) → Stream
// streamFileBy :: (path::String, encoding::String, separator::String) → Stream
// streamLines(path) equivalent to streamFileBy(path,"\n")
// writeStream :: (path::String, encoding::String) → Stream → Continuable Either Error Int
// readFile :: (path::String, encoding::String) → Continuable Either Error String
// writeFile :: (path::String, data::String, encoding::String, mode::Int) → Continuable Either Error Int
// appendFile :: (String, String, String, Int) → Continuable Either Error Int
// copyFile :: (src::String, dest::String) → Continuable Either Error Int

A Continuable is a plain JavaScript function which takes
another function (a continuation) as an argument, and then
does (potentially) some I/O, calling that function with the
results.

It's similar in purpose to a Promise; one difference is that
no I/O is done until the continuation is supplied by the
caller, which seems to simplify some things.

Similarly, a Stream is a function which takes a function as an
argument and does some I/O, calling the function with messages
for each chunk of data, EOF, or I/O error.

Once the above API is done (probably this weekend) I'll add a
traditional node.js-style API as a thin layer above this one.
For that, just read "Promise" and "EventEmitter" in the above
for "Continuable" and "Stream" respectively.

--
http://inimino.org/~inimino/blog/

[Ben Taber]

> Why do you think its incomplete? I've been using it for reading/
> writing files quite a few times in the past.

I think i am mostly confused by the two different interface styles
exposed. exports.write and exports.read start the file, so I
blissfully didn't read to the bottom and started using those. I later
noticed the exports.File constructor that attaches write, read, open,
close methods.

Is the intention to standardized on one of those two interfaces, or
leave both available?

I was having difficulty with exports.write as it does not pass along
the posix emitError arguments (though I assume those are available
through the debugObject/debugMessage functionality). I think it would
be beneficial to pass along event arguments, especially in the case of
an error, within the closed doWrite function inside of exports.write.

(lines 33-35)
.addErrback(function () {
posix.close(fd);
promise.emitError(); //should this be promise.emitError.apply
(promise, arguments); ?
})

I'm not really sure what the convention is in other areas of Node when
you are essentially just passing along an event message.

It does look like the functionality I am looking for, which is using
the disk as state persistance in the event of application shutdown or
crash, is completely supported. I will experiment with the File class
as opposed to the static methods and see where that gets me.

Thanks