Questions about superbuffer

[DanielHZhang]

Hey @yandeu, I was heavily inspired by your work with typed-array-buffer-schema. There were a few things missing that led me to create my own fork, and most were functionality specific to my own use case, which was why I did not create issues on your repo.

Some of these features include:

• UTF-8 encoded strings of any length
• Sorted schema keys
• Arrays of TypedArrayViews (i.e. uint8[])
• Removing support for special types digits and length
• No dependency on lodash or lodash.set
• Infinite nested objects/schemas within schemas
• Array serialization and deserialization (toBuffer([{}]) and fromBuffer([{}]))
• Automatic Typescript inference for toBuffer and fromBuffer:

const model = Model.fromSchemaDefinition('name', {x: uint8, y: uint8})
const buffer = model.toBuffer(/* Typescript explicitly requires object of type {x: number, y: number} here */)
const object = model.fromBuffer(arrayBuffer) // object is type {x: number, y: number}

I was willing to sacrifice compression % to achieve most of these. Feel free to port over anything you think would be useful for typed-array-buffer-schema.

---

Regarding node-webrtc, it's an immediate no-go for me (which is a shame because geckos.io/server is great) because of poor docker support (multiple open issues of segmentation faults and memory leaks). I tried replacing it with werift, but that project is not stable because it is in early stage development. Right now I've fallen back to using pion-webrtc in a Go server, and relaying messages received to a node server via zeromq.

[lalalune]

Same boat. @yandeu i started with your project but struggled with needing deeper levels of structures, and after spending a few hours struggling to implement myself, I dug around the forks and ended up on Daniel’s solution, which worked like a charm.
To the point of making a new repo — most open source devs get very little out of maintaining them for other people, most anonymous pull requests are never accepted or reviewed, the politics are complex for maintainer and contributor, but I can say I’d probably do the same thing, especially since I want to point my package.json to NPM packages and not git branches. However, it would benefit the multiplayer JS community quite a lot of people if they were the same project, as the geckos.io ecosystem is very promising and often talked about in multiplayer JS circles.
I have some ideas that I personally need, like “smallest three” quaternion packing, which I Would need to put directly into the library to not mess with the current quaternion API semantics. Write once for this feature would be nice 👍