Difference between revisions of "Talk:TypeSystems"
| Line 9: | Line 9: | ||
John, you only need to break the spec to allow everybody to use fixed length arrays. If we only use them internally in our types, then its not an issue. Personally I think this is a pretty major omission in Protocol Buffers, possibly worth breaking spec for. That being said, it doesn't require breaking the wire format in anyway. In fact, the whole idea is to have the existing implementation do all the real heavy lifting. Basically what we'd like to provide is a friendlier interface and larger variety of basic data types, which boils down to appropriately massaging the IDL and wrapping the output of Protocol Buffers. | John, you only need to break the spec to allow everybody to use fixed length arrays. If we only use them internally in our types, then its not an issue. Personally I think this is a pretty major omission in Protocol Buffers, possibly worth breaking spec for. That being said, it doesn't require breaking the wire format in anyway. In fact, the whole idea is to have the existing implementation do all the real heavy lifting. Basically what we'd like to provide is a friendlier interface and larger variety of basic data types, which boils down to appropriately massaging the IDL and wrapping the output of Protocol Buffers. | ||
--[[User:ewencp|ewencp]] | --[[User:ewencp|ewencp]] | ||
| + | |||
| + | |||
| + | I think we need to break protocol buffers syntax for a couple of things: fixed length arrays and flags. Mangling was mentioned for fixed length arrays, which is ugly but maintains compatibility. Flags are harder because we need to specify number of bits. There will sometimes be flags that take more than 1 bit and we probably also want to be able to specify the size of flags (although that could just be flags8, flags16, etc). We also haven't talked about additional types that can be defined in protocol buffers, but might be nice to provide builtin support for, like map, which might need new syntax. If we break syntax, then these are probably worth adding to make them clearer. | ||
| + | --[[User:Ewencp|Ewencp]] 07:41, 27 February 2009 (UTC) | ||
Revision as of 07:41, 27 February 2009
Quaternion can be transported as a Normal3f (W value is calculated on the receiving side). The Angle type seems like overkill; you could define floors and ceilings for every numeric value you send in theory but there are diminishing returns to doing it at the protocol level.
I'm interested to see the results of this work. Do you have to break the Protocol Buffers spec to add support for fixed length arrays? Sending UUIDs and hashes will be a critical part of any virtual world system.
Also... this same conversation is happening on the MMOX list (https://www.ietf.org/mailman/listinfo/mmox). It would be great if you could send a note to the list talking about your reasons for choosing Protocol Buffers, tradeoffs it has compared to systems like Apache Thrift, and how you are working around the limitations. --Jhurliman 03:07, 21 February 2009 (UTC)
John, you only need to break the spec to allow everybody to use fixed length arrays. If we only use them internally in our types, then its not an issue. Personally I think this is a pretty major omission in Protocol Buffers, possibly worth breaking spec for. That being said, it doesn't require breaking the wire format in anyway. In fact, the whole idea is to have the existing implementation do all the real heavy lifting. Basically what we'd like to provide is a friendlier interface and larger variety of basic data types, which boils down to appropriately massaging the IDL and wrapping the output of Protocol Buffers.
--ewencp
I think we need to break protocol buffers syntax for a couple of things: fixed length arrays and flags. Mangling was mentioned for fixed length arrays, which is ugly but maintains compatibility. Flags are harder because we need to specify number of bits. There will sometimes be flags that take more than 1 bit and we probably also want to be able to specify the size of flags (although that could just be flags8, flags16, etc). We also haven't talked about additional types that can be defined in protocol buffers, but might be nice to provide builtin support for, like map, which might need new syntax. If we break syntax, then these are probably worth adding to make them clearer.
--Ewencp 07:41, 27 February 2009 (UTC)