Closed msoucy closed 9 years ago
Any progress on that? It would be really great if your library could be used without allocating temporary buffers.
I've been away from the project for a bit, but this is next on my agenda. I'm starting on the deserialization first.
Great, thanks a lot.
So, I'm not entirely sure about the API that I've been building - is this the "correct"/"cleanest" way to do it?
Yes, the API looks good. You might simply overload serialize
instead of naming it serializeTo
, but that's merely a matter of taste.
I'll try to test it this weekend and will report back on my findings.
Can this be closed now? Should also release a new version 1.1.2.
I believe it can. Did your testing find anything else that needs to be taken care of with range support?
Also, this is the last remaining issue for 1.2.0, so I'll probably be tagging that when this gets closed.
I think I found a bug when decoding nested messages, but that needs a little more investigation.
SYN - status?
SYN - status?
Sorry, no time right now, busy with release building.
No worries, take your time
I can no longer reproduce the bug, maybe my D test server and the python client were out of sync. So good to go for a new version from my side.
Alright, in that case I'll close this and push the next release!
Thanks, I haven't yet benchmarked/profiled receiving, but work on that shouldn't affect the API.
Deserializers should handle any arbitrary input range of ubyte, not just ubyte[].
By the same reasoning, serializers should handle output ranges.