I think we should tweak the serialization format for variable length element types so we can optimize the positional access of an array element. Better if we do it now, b/c changing the format later is going to be painful. Here's a proposal:

* vint for the number of elements (which we're doing now)
* array of smallest fixed length numbers that can store the offset to the last element value. For example, if the total array size is < 256, we can store the offets in an array of single bytes. if total array size is < 65534, then you can store the offets in an array of two bytes, etc.
* values concatenated together. I think we can get away without storing a terminator byte, since we can calculate the length based on the next offset.

In this way, when you implement array access, we can seek into the array very efficiently through an array lookup into the offset array based on the position of the element you want. Size-wise, it's not much different than this, we're just storing offsets instead of lengths.

I also think we'll want to allow arrays to be used in the row key down the road, so we'll have a different serialize format for these (since we'll need the serialization format to reflect the natural sort order). For now, we should disallow:

* Having an array type in the primary key. See MetaDataClient.createTable() for this.
* Indexing a key value column that's an array type. See MetaDataClient.createIndex() for this.

What do you think?