There are several undocumented AMF types, Vector.<T> is one of them,
however it is only partially implemented (it's also known as "type 13"
because 13 eventually is the value of the tag produced in AMF).
It is only half-baked because it doesn't preserve the runtime type of the
vector.
There are some positive and negative sides to consider when creating custom
serialization of vectors. Vectors are dense, which means that they are
_easier_ to serialize then ECMA arrays (the later consists of two
compartments, one for the dense part and another for the sparse part). I
would go about vector serialization like this: create a serializer method
that writes the IExternalizable type which would contain the record
generated from vector and one field for the type - so we use the same
routine for serialization of all vectors.
Why not use arrays - few people know, but arrays pose a danger of "memory
asplodes" attack :) since in many languages (such as, notably, Java), when
arrays are deserialized the created array instance will be dense. So, this
code:
var array:Array = [];
array[int.MAX_VALUE] = "hello";
connection.send("service", array);
will cause on the Java end something like this:
new ArrayList(0x7FFFFFFF);
which would usually bring down the unsuspecting Java server.
With vectors you can't do it, or rather it will explode on the client side.
The problem is many AMF implementation are incomplete in that they don't
treat IExternalizables in any way... or, selectively.
This problem is also repeated in Dictionary class, which is also partially
implemented in AMF, but has bugs pertaining to item deletion.
I'm afraid that's what we can do, given only the AS side of things. I
reckon there must be a bug for that in Flash player bug base, but it's too
tedious to search it since it moved from JIRA :) so I can't find it.
Best.
Oleg
