"...serialization is the process of saving an object onto a storage medium (such as a file, or a memory buffer) or to transmit it across a network connection link such as a socket either as a series of bytes or in some human-readable format such as XML. The series of bytes or the format can be used to re-create an object that is identical in its internal state to the original object (actually a clone). This type of serialization is used mostly to transport an object across a network, to persist objects to a file or database, or to distribute identical objects to several applications or locations.
- This process of serializing an object is also known as deflating an object or marshalling an object.
- The opposite operation, extracting a data structure from a series of bytes, is deserialization (which is also referred to as unmarshalling or inflating)."
-
Wikipedia entry on
Serialization
Most any kind of remote procedure calling(RPC) involves some sort of serialization. In fact inter-script communications in
SecondLife is essentially RPC.
XML-RPC in
SecondLife only seems to support
strings and
integers.
The
example script
ExampleListConversion provides a rudimentry sort of serializtion for sending the values of variables between scripts over chat channels. However this script does not address the precision loss that occurs when
floats,
vectors, and
rotations are
typecast to strings. This page exists to make LSL scripters aware of this issue, to find a method that can serialize these types with out precision loss, and maybe to champion the cause of having
LindenLab create
built-in LSL functions to facilitate serialization(especially floats, vectors, and rotations).
Serialization of other types
As far as I know
integer,
string, and
key do not experience any kind of data loss when
typecast to and from
string and are thus not considered priorities for special serialization support.
lists on the other hand are a whole other animal all together and is in fact what the
ExampleListConversion script attempts to seralize.
What would a built-in LSL function to help serialize floats (and consequently vectors, and rotations) look like?
Such a function would probably look and perform like the
Float.floatToRawIntBits(float) and
Float.intBitsToFloat(int)functions from the Java standard library. This would allow us to typecast the resulting
integer to a
string and then back to
integers on the recieving side and then subsequently converted to the exact same float value that was sent. These functions should be fairly straight forward and relatively simple for
LindenLab to implement.
Float Serialization Hack - First Idea - Strip and Multiply
First the exponent of the float would be recorded. Then some method of stripping and recording the most significant digit from the float and then subtracting that from the float then multiplying the float by ten. The process would be repeated until one was reasonably sure to have gotten all significant digits stored in the float. Then the significant digits along with exponent would be encoded into some sort of string representation that could be spoken on a
SecondLife chat channel. On the other end the float would be reconstituted possibly by dividing an
integer by the exponent typecast to a float. Anyone up for creating an end to end implementation of this? This hack seems like it would be really inefficient. I challenge all you geniuses out there to come up with a more efficient way to do this. Also I would guess there would be some examples where the float does not reconstitute exactly the same on the recieving end. And of course this would not even begin to handle
NaNs properly.
BlindWanderer posted
LibraryFloat2Hex which seems to get the job quite nicely. I have yet to test it out but it looks like it should do the trick. Thanks
BW.
If you want the float-string to be in scientific notation you should see Float to Scientific Notation but be warned, it's slow, for anything that needs speed, you should use LibraryFloat2Hex - BW
I've posted code at
LibrarySerialize which uses BW's
LibraryFloat2Hex and is pretty much-based on
ReadyJack's original code, with a couple of implementation changes. It seems to be holding up pretty well, but I could use some more people hammering it to work out bugs/performance issues. -
ShadowGretzky
Q: What is a NaN, as reference three paragraphs above? - St. Psaltery
A: See NaN.