multipart parsers?

[jonathanong]

like busboy and multiparty

[dougwilson]

or something. we'll have to think more on this one. multiparty has a simple interface but the parsing is way too loose; i haven't really looked into busboy, mostly because the interface is hard to use with a million function options, lol

[jonathanong]

ya. ideally all those limit events would just be errors. i don't want to attach a bunch of listeners everywhere. it also doesn't emit a close event, which sucks haha.

personally, i never use multipart anymore so it's up to you guys. but there should only be one multipart parser.

[rlidwka]

but there should only be one multipart parser

you mean, there should only be one multipart parser except busboy and multiparty?

/me searches xkcd for "how standards proliferate" :)

[jonathanong]

one parser in this org

[dougwilson]

No description provided.

[dougwilson]

one parser in this org

this. we don't mind multiple implementations on npm :) but our goal in jshttp is to have a bunch of low-level http modules done well. no reason to write a parser multiple times, lol, that parses the same thing.

busboy and multiparty are both out there now. I don't have any immediate plans for multipart right now, since the role is fulfilled on npm, haha.

we should, though, have some kind of "see also" section that points to alternatives to our stuff or to stuff we do not yet have (like multipart), so at least people can come here for a list.

[rlidwka]

have some kind of "see also" section that points to alternatives to our stuff

I really thought about such section inside package.json making it somewhat standard across npm modules.

[jonathanong]

since @mscdex is node committer and we're part of whatever TC we're a part of, @mscdex how about moving busboy here?

i don't mind moving https://github.com/andrewrk/node-multiparty either @andrewrk. i don't really care about adding both since they're both pretty solid right now.

[andrewrk]

I don't mind transfering the multiparty repo. I couldn't be happier with @dougwilson as the maintainer.

As for parsing too loosely the spec and limit events, I agree. I forked it from formidable but in retrospect I have no idea why I didn't just start from scratch, it would have probably turned out better.