On Jan 30, 2008 8:20 AM, Tomash Brechko <[EMAIL PROTECTED]> wrote: > On Wed, Jan 30, 2008 at 07:50:58 -0000, Kieran Benton wrote: > > How about standardising on something like json? Either that or > > we're basically going to have to put a custom serialization rules > > together each client has to follow? > > I think there's simply no automatic solution to the problem. That's > because the problem itself is not how to get different clients agree > which flags to use, but how to get different platforms (programming > language included) to agree on how to interpret serialized data. For > instance, while we may agree that certain flag would mean the data is > a serialized map (i.e. the key/value container), not every language > has maps built-in (and some have more than one), thus the client will > fail to reconstruct the data structure automatically. > > The solution to the whole problem is to have serialization hooks in > each client you use. Then you would simply agree how you serialize > your data across the clients you use (be it a custom format, or some > pre-existing), and implement the hooks for each client. This makes > sense even for a single client when you can implement less generic but > more efficient serialization for your needs. > > So the remaining thing would be to agree which flag to use to signal > that the data is serialized. The answer is 0x1 ;). > > > On a side note, some clients encode the type of serialized data in > flags rather than data itself. I think this is something not to do, > because: > > - type info can alway be encoded in the data section itself. > > - nested structures would call for such embedded encoding anyway. > > - only when all information is in the data section you may call it > true serialization: the data is self contained and you may pass it > around (store to a file for instance), without the need to wrap it > in yet another format to store "type flags" along with it. > > Such clients should be fixed then.
A nice succint response that makes perfect sense, however would it not also make sense to get some agreement on some cross-platform 'standard' for these serialisation hook implementations to make it easier for Joe Bloggs to take Client A, and Client B off-the-shelf and have them work together, I understand exactly what you're saying about the data-type in flags approach being a corruption of the flag intent, but if there was to be an agreed 'cross-platform serialisation' strategy (such as the first one or two bytes of the actual data being the 'serialisation flag' ) then the client developers could (have contributed, or provide themselves) default implementations of these serialisation providers that would be overridable by consumers of the client, or 'just work' together. Just supporting a subset of types (booleans,chars, byte, byte array, utf-8 encoded strings, in32, in64 etc.) would provide a 80% requirements hit for most people, and those wishing to supported more exotic types (such as lists,dictionaries, maps et al) could still use their own custom serialisation routines by building on the provided 'platform agnostic' approaches ? - ciaran > > > > -- > Tomash Brechko > -- - Ciaran
