About Binary Serialization
Hi, I did not want to pollute your Binary_Serialization
- that's what talk pages are for, so i am moving your comments to keep things organized.--eMBee 17:29, 21 October 2011 (UTC)
page with kibitzing, but I still wanted to make a few comments. That said, my topics are intertwined and perhaps ill-formed:
- Objects are the anti-serialization.
- Some arrays have multiple dimensions.
- Some integers can be large.
- Serialization and RPC are different, though related topics.
So, first off, you cannot serialize an object. You can serialize a copy of an object, but objects are things you refer to, they are not their state. This leads to numerous complexities when people try to serialize objects (or when they confuse message passing with serialization). You could hypothetically serialize an object reference, but conceptually what you would want to do is publish an RPC interface (which raises issues like object lifetime and references, security and so on). Similarly, you can serialize object state, and descriptions of an object's interface, and these are also topics which can grow without bound and perhaps deserve an encapsulation barrier. --Rdm 15:16, 21 October 2011 (UTC)
- i am aware of the difference. the task description may not be clear (which is one reason for not putting this page on a public namespace yet, and it also makes me even more happy to get your comments)
- the task does describe the binary format of a message passing system. objects are not serialized here. the message is serialized.
- the task is only the first step towards a full RPC interface which covers all the issues you mention.
- the RPC interface is already complete, implemented and in active use, so the format will not change. however criticism of the format is welcome. there may still be room to extend it.
- the object lifetime is long. objects with ids are stored in a database until deleted by a user.--eMBee 17:29, 21 October 2011 (UTC)
Second off, a matrix is an array with two dimensions. Sometimes you might have reason for arrays with more than two dimensions. In the general case, an array might be a region of memory, a type, and a list of dimensions (where a list of dimensions is a degenerate array whose type is known and whose list of dimensions itself only has one dimension and that 1 element list is a further degenerate case). All of which generally makes it popular to only deal with degenerate arrays... Note though, that I have implicitly assumed that all elements of an array are the same size. If you need to deal with variable sized elements you can degenerate this to an array of references to elements, or you could degenerate it to something else (like the linked list where you have a degenerate array containing two references, the second of which is a reference to the rest of the linked list). You can also degenerate the concept of a reference and have variable sized elements and force the reader to walk through each element to find the nth element.
- arrays can be nested and contain objects of variable size
Arbitrary precision integer implementations share concepts with arrays or degenerate arrays (they wind up being variable sized).
Getting back to objects, the whole concept of RPC can be interesting and useful, but it's probably best to implement as a separate layer from serialization. Meanwhile, your current draft has a "transaction id" which I think does not belong in serialization but could belong in RPC.
- well, the transaction id needs to be sent over the wire, as it is used to match a response to to the request
- the focus of this task is the binary serialization of a data structure. it might be possible to remove the header which would not affect the complexity of the task, but i don't think keeping it is a problem.
- if this task works out, there may be follow up tasks to implement the rest of the RPC interface and finally a maybe even a client that can talk to a live server.--eMBee 17:29, 21 October 2011 (UTC)