merge muxado2/wip ? spec?
jbenet opened this issue · comments
Hey @inconshreveable may want to merge muxado2/wip? Also, may be nice to have a spec for interoperable impls in other languages? even if just an example based listing of frames
And a more general thought: ideally, it could be http2-compliant so other languages could use http2 based muxers to talk to muxado, but not sure how much muxado departs from the spdy framing. maybe that ship's sailed and docked elsewhere by now.
Yeah, I've been putting it off just because I've been afraid of 'finalizing' a public API, but I think the right thing to do is just take one more pass at it and say to everyone, "pin your dependency if you don't want to break". It's very unfortunate there's no official tool-supported way to deal with this problem for library authors.
The ship has sailed on the http2 compat, but there should definitely be a spec for this, I agree.
I'm going to try to take another pass at my open source projects in the next week or so after I finish up some business-critical work first.
thanks @inconshreveable ! and no rush :) -- i should be clearer: we dont depend on muxado2 yet, so no worries on our end, just figured i'd push the ball a bit here.
i want to drive towards a "common string muxer interface" to use everywhere, that layers on underlying transports when possible, or uses a common standard well-scoped muxer (muxado2?) whenever the transport doesn't mux streams. (basically: jbenet/random-ideas#34), but it doesnt seem likely to come soon.
+1 for merging wip into master. I just came across this project as I was trying to build something very similar, and I'm very happy I don't have to roll my own version of muxado! The fixes in the wip branch will be critical for my application, especially the improvements for reduced memory usage.
Thanks for building and continuing to support this project @inconshreveable!
+1
merged wip into master. should have done this a long time ago. when i get a spare weekend I'll try to get some docs up about the policy but it's basically going to be what the go community has adopted:
- If you want any API stability, vendor.
- Any API changes will be documented