Streaming API

Nick	Message
daurn	@thibaultcha: I don't see why we couldn't have a multipart library with a streaming api that doesn't depend on any openresty specific apis.
daurn	@thibaultcha: did you read the irc transcript with furq?
daurn	(oh: and it should have both multipart encode and decode)
thibaultcha	@daurn: I haven't read it, but I do agree that this should be totally feasable in an unopinonated streaming fashion
daurn	thinking about decoding api: multipart/formdata can be nested
daurn	I think there would be SAX-style 'pull' with events like "start of part" "part body chunk" "part body chunk" "end of part"
thibaultcha	only I wonder, such an API would not be able to append or remove fields on the fly... Or would it?
thibaultcha	Actually, it could, if the API handles it pre- encoding/decoding...
daurn	@thibaultcha: there should be a streaming decoder and a streaming encoder. if you wanted to append/edit/remove then you'd have something in the middle there as a filter
thibaultcha	yeah
thibaultcha	that'd be nice
daurn	@thibaultcha: how would you feel about doing this under the 'lua-multipart' project? as a new major version
daurn	only thing is that I'd like to have the lua-http 'headers' object available
thibaultcha	Any reason you see for wanting to stick under the lua-multipart project though? Just curious
thibaultcha	Otherwise it'd be fine as a major version yeah
daurn	@thibaultcha: well it's a nice succinct name ;)
thibaultcha	Indeed

Start by reviewing the existing multipart parser and how lua-http's headers object could be used. Define a design for OpenResty-independent streaming encoding and decoding, including nested multipart data and SAX-style events; done requires agreement on the API before implementation.