search

jshttp / jshttp.github.io

https://jshttp.github.io/
MIT License
47 stars 3 forks source link

multipart parsers? #25

Open jonathanong opened 10 years ago

jonathanong commented 10 years ago

like busboy and multiparty

dougwilson commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

one parser in this org

dougwilson commented 10 years ago
dougwilson commented 10 years ago

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 commented 10 years ago

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 commented 8 years ago

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 commented 8 years ago

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.