Best way to pack nested unknown structs ([]interface{})?

<p>Hi <a href="/r/golang" rel="nofollow">r/golang</a> </p> <p>We are implementing a framework, which uses the abstraction of tuple spaces and tuples. Tuples can contain any type as a field and as many of them as the user wants ([]interface{}). We want to transmit these tuples across a network and so far we&#39;ve tried with both gob and JSON.</p> <p>We have had problems with both gob and JSON, when sending structs as interface{}. </p> <p>In gob we have to register structs on both sides of a connection, otherwise gob won&#39;t know to encode and decode them correctly. As this is a framework, the tuple will be able to contain user specified structs, meaning that we can&#39;t register them in the framework. This would mean that every user in the network using the framework would have to register every struct used. </p> <p>In JSON when passing nested structs, when a struct is of type interface{}, it is encoded as a map. Again we can&#39;t specify the specific struct every time, as the user can create their own structs and we can&#39;t pass it.</p> <p>We know it sounds confusing but hopefully you follow our problem.</p> <p><strong>TL;DR: We want to encode and decode nested arbitrary structs.</strong></p> <hr/>**评论：**<br/><br/>drvd: <pre><blockquote> <p>arbitrary structs</p> </blockquote> <p>Good luck!! You will fail but I wish you all the best and hope you won&#39;t hurt yourself too much.</p> <p>&#34;Arbitrary&#34; means it may contain self referential structures</p> <p>&#34;Arbitrary&#34; means it may contain potential infinite data like linked lists with circles.</p> <p>&#34;Arbitrary&#34; means it may contain channel types, possibly buffered channels with values in them.</p> <p>&#34;Arbitrary&#34; means it may contain stuff which must not be copied like sync.Mutex</p> <p>&#34;Arbitrary&#34; means it can contain unsafe pointers or C stuff.</p> <p>Drop arbitrary from your list of requirements and think about what types you really need to transmit. Probably it boils down to simple non-recursive, finite value types. Think about how you would like to use the deserialized form: Into what shape/type/data-structure would you like it to be deserialized. There aren&#39;t too many (sensible) possibilities: &#34;slice of ...&#34;, &#34;map from ... to ...&#34;, &#34;tree of ...&#34;, you get it. Which is easy to use? Which is homogeneous? Thinks which wire format would allow to construct such a deserialisation.</p> <p>JSON is fine, the deserialization as map[string]interface{} is almost as good as it will become. Other formats to consider: S expressions or XML. </p></pre>twoism: <pre><p><a href="http://grpc.io" rel="nofollow">http://grpc.io</a></p></pre>jerf: <pre><p>I would very strongly suggest that you consider the tuples to be a serialization method, and that by default you will serialize and deserialize these into well-typed structs. You can provide operations to query the tuple space or manipulate the tuple space directly to your hearts content, but no matter what you do, you have to have a layer in the interface where the user has to cast all these interface{} values into concrete types anyhow, so it might as well be a nice deserialization step, rather than requiring a lot of type assertions.</p> <p>You&#39;ll also want to understand the difference between a serialization format, and the code that supports it. <code>encoding/json</code> is pretty much entirely unsuited to what you want to do. Even if you could bash it into compliance, it&#39;ll be almost entirely by hacks and overriding a ton of stuff. It is possible you could develop what you want with another JSON library, though, you&#39;d have to look around.</p> <p><code>encoding/xml</code> is closer, as it has the capability of decoding different kinds of concrete structs into an interface value, by keying off of the tag name. But it still is a bit limited. Gob is more flexible.</p> <p>A final alternative is to write your own wire format. You&#39;re going to be grunging around in Go reflection code anyhow before you&#39;re done, so you&#39;re going to be 80% of the way there before you&#39;re done anyhow. It may be the case, depending on your needs, that your optimal solution is simply to learn reflection, write the serialization and deserialization you&#39;re looking for, and once you have that in hand to do the relatively minor extensions of the code at that point to go ahead and write up your own wire format.</p> <p>Just some thoughts.</p></pre>