Thanks, I’ve been happy too.
my ex-colleague, clients are trying preview.
I've been pointed one immediately. #698 :)
MessagePackSerializer.Deserialize(Stream)methods in v2.0? We can support that scenario much better with #388 using a class that can track state between reads, thus enabling reading a message at a time from the stream but in a highly performant way. I think the way
MessagePackSerializer.Deserialize(Stream)works today is unintuitive, and fixing it later to allow reading a message at a time wouldn't work because we need to store state between each read. I could even do it for 2.0 if necessary, but we'd need to agree on the removal of the method first.
DeserializeAsync (context.ModelType, request.Body, request.ContentLength)
Serialize(Stream)method but no
Deserialize(Stream)method feels odd.
Stream.Sliceextension method that already restricts reading to a given length. But having it built in to messagepack might be useful for folks who don't have that.
MessagePackStreamWriterclass? The reader of course allows for very efficient, async reading from the stream and can return
ReadOnlySequence<byte>slices with entire msgpack structures in it. The writer could implement
IBufferWriter<byte>so that it can be used to serialize with
MessagePackSerializerdirectly. It might use
Sequence<byte>internally for buffering but would allow us to be writing to the stream in the background even while serialization occurs.
MessagePackSerializerthen folks would look at it just as a serializer and not as a streaming control system as well, and the two class names I propose would be pretty discoverable, IMO. As people type
MessagePackSthey would see the Serializer as well as the StreamReader/Writer classes in the completion list. But if we wanted it even more discoverable, we could add static
CreateStreamWritermethods to the
ref StreamReaderStateparameter to the
Deserialize(Streammethod that folks would repeatedly pass in each time they read from the same stream, and that would allow us to incrementally read from the stream. This struct would have a bunch of internal fields that would retain the state we need (e.g. the buffers we read too far on). The only question would be what we do with
DeserializeAsyncsince async methods can have
refparameters. We could use a
StreamReaderStateinstead of a struct to allow the async method to work.
I commented on PR, but I think State is a good idea.
It's a somewhat uncommon API, but it should be fine.
Even if there is a State, I think that it is not bad to default to reading until the end if it is not specified.
Here is my image of usage:
90%-Ok to read end.
9%-simply contiguous block.
1%-concatenated other things.
90% situation, read to end is fastest.
9% situation, use state is good to use.
1%, we don't care.
refparameters, I can use a
StrongBox<state>parameter to achieve the same result.
AsyncRef<T>. Are those existing types?
StrongBox<T>is an existing type and why I picked it. But anyway it's a moot point because #699 is now complete. We don't need any of these solutions.
StrongBox<T>because boxing is something that happens automatically all the time, but this "strong box" forces a box around a value type that won't come and go automatically. It's all explicit. So I guess that's why they called it "strong".
StrongBoxwas a existing type
Standard way of publish unity assets is source code level(many unity asset stores libraries, unity package manager).
It would be the reason why Unity chose UPM (Fork of NPM) instead of NuGet.
for net46 and netstandard20 in single unitypackage.
I want to support use dynamic assembly if can(in UnityEditor, PC, etc.).
net46 has ref-emit but netstandard20 requires external library.
In includes external library(System.Reflection.Emit), it occurs error on net46.
This can be solved by separating unitypackage, but one unitypackage is preferable.
I only care about mpc, so I think patch is appropriate (major, minor will need to be more considered).
It was a failure for me(and contributor) to choose 2.0 for some PR.
However, it may be a difficult rule for contributors to choose 2.0 as the base of the patch for Bug Fix.
Not about mpc, but can become patch(?)
(I received some users uses CompositeResover.Create and does not work on IL2CPP(warning is not noticed!)
v2.0in order to release as a 2.0 patch? I tend to like to get ahead of these things during the PR by encouraging folks to rebase on v2.0, even if targeting master so that if they change their minds and want to merge into v2.0 we are free to do so without having to 'cherry-pick' commits which makes tracking fixes harder. But I'm sure we can special case these and copy the changes to v2.0 if they're stable changes that fix things without adding API.
it may be a difficult rule for contributors to choose 2.0 as the base of the patch for Bug Fix
We could fix this by making v2.0 the 'default' branch in the repo.