Closed sigiesec closed 7 years ago
No No No ... don't do this, ever.
A ZFrame is the fundament on which ZeroMQ is based on. Just believe me, you don't want to remove it.
@metadings Actually, I don't believe you ;) Could you please elaborate why you think it is essential? I can imagine that it can be used in a layer on top of ZSocket, maybe providing extension methods to streamline interaction between the layers.
Look, a ZFrame is a real C pointer.
In C#, you do always have the CLR moving bytes around, if you don't use GCHandle to fix it and the like. (In C# class ZFrame
is using an IntPtr
, specifically the DispoIntPtr
instead.)
The ZFrame, as a really hard C pointer, you also can zero-copy the ZFrame right in place.
So please, just, don't.
Ok, I understand that. I also think that is a good reason to keep ZFrame. However, given that it is so fundamental, there should be some hint in the code. Would you add an explanation? Otherwise, I can also do that. Then I am fine with closing this issue :)
Yes, some documentation would be nice :smile: Preferably in XML. (Please use TAB instead of SPACEs)
This is so stupid. Let this issue be closed. You do not want to remove ZFrame from ZeroMQ.
Please observe your language.
This issue should stay open until the rationale behind ZFrame is documented.
IMO ZFrame is unnecessary, it makes clrzmq4 unnecessarily complex, mixes multiple concerns (frame data, Stream, TextReader, TextWriter), and does so in a way contradicting the design of the .NET Framework. It can be replaced by byte[]. Other usages can be implemented on the client using the MemoryStream, StreamReader and/or StreamWriter classes provided by the .NET Framework.
Some frequently used functionalities might be provided as extension functions operating on a ZMessage or byte[], but this is not really in the scope of clrzmq4.
BTW: jzmq also uses a byte[] to represent message frames.