As I re-read now my replies, I see how they are a little hectic, and the important thing probably skipped your attention. I will first try to explain what is the problem with vectors when they are serialized / deserialized, then I will "reflect" on the current serialization mechanism in the flash player, and then to the framework. Then, some suggested changes.
1. When reading AMF format, the parser needs to maintain 3 tables: - data table: any string, number, byte array is referenced in this table if it is more then 2 bytes long, this is done so the objects can be reused. - object-properties table stores the descriptions of sealed classes already [de]serialized, so that any two objects of the same type would not send their type description. - object-references table stores references to already serialized objects, similar to the first table it helps reusing objects already serialized (this is why recursive and many-to-many relations may be serialized). Vector and Dictionary are not parts of the AMF 3.0 format. Adobe implemented them in the player, but, obviously, had tried to not to break all other implementations which knew how to read AMF 3.0 as documented. Vector uses it's special format for writing it's data, which other implementations cannot read (possibly Adobe's own BlazeDS can, but not anyone else that I know of). If objects inside vector were counted towards the references inside the general references table, if an AMF package containing a vector was to be read by an implementation unaware of vectors (and not being able to count the references inside vector), the references table would break. This means that today using vectors in AMF is a big no-no, because it is sub-optimal. It is an experimental feature, but if you care about traffic utilization you should not do it. Same thing with dictionaries - no conforming implementation knows how to read them, that's why references inside dictionaries don't count towards the general reference count and are serialized every time in full volume. 2. The design of AMF serialization API in Flash player is short-sighted. There are two major problems with it. a. It is unaware of security sandboxes, (later versions tried to fix this, but they realized that the "fix" was both incomplete and broke a lot of other things, so they sort of rolled it back with a warning). Originally, aliases were registered universally for all sandboxes, this later appeared to be a problem, as if any loaded SWF, that had to be unloaded would register it's own aliases, that SWF would fail to unload. The original "fix" suggested that classes be registered each for the sandbox it comes from. This broke a lot of code that relied on the old functionality. So, today, the player is trying to guess what to do - if the call to deserialize a class doesn't find an alias in the current sandbox, it will look in other sandboxes too. Which, in my opinion, is even worse, because it turns the testing of this feature into a nightmare. b. Player's serialization API make it impossible to efficiently serialize IExternalizable objects. This is so because the reference tables are not accessible to whoever is trying to write AMF object on their own. So, even if you are serializing two IExternalizable objects that reference the same object, you have no simple way to make sure the referenced object is written only once. This, for example, will cause that if your value object has two ArrayCollections that contain mostly the same items, concatenating two collections before sending them will yield significantly smaller file, then if you left them be two separate collections. c. The API designed to be global. They suffer from all the same problems typical for global variables - random parts of the application can set or unset them and in complex situations you have no idea what is going on in your code. 3. Framework code (which is, frankly, none of my business, but in case you wanted to know...) generates from [RemoteClass] meta ridiculously bad code in the FlexInit class that registers all aliases in one go. I usually advise against using this meta because of the following reasons: a. It makes the process impossible to control and very problematic to debug. b. You will not have any pointer in your code to the alias, for which the class has been registered, so, if later you wanted to find the alias w/o knowing what was the aliased class, or, if you eventually registered another class with the same alias - you can't do it. Framework code uses RemoteMessage and few more other classes that the implementation of AMF 3.0 has to know how to handle, even though these classes aren't part of the format. === What I suggest be done. - Pressure Adobe to release AMF 3.1 spec and implement it in the player in the way that references inside vectors and dictionaries count towards total count. Remove undocumented features from AMF 3.0, so that conforming implementation wouldn't have the problem of running into something they neither can understand nor skip. - Pressure Adobe to change the AMF serialization API in a way it stops being global. - For the time being, it is possible to build the model for serialization / deserialization, which is not global, which would only register aliases for the writing / reading operation, and unregister them after the operation finishes. I've posted the API, as I would like them to be before. * * * I know that my view of the framework many people find too controversial, that's why I put it separately: - Make ArrayCollecion not serializable by default, likewise ObjectProxy - the reason being that no one should use them to serialize the data they represent. If you wanted to properly serialize the data presentation, which, for example, ArrayCollection is, you would also need to serialize bookmarks, cursors positions, sorting order, filtering etc. The current serialization _only_ serializes the data, which is wrong both factually (as lots of data is lost) and in terms of design (if you wanted to serialize the data - go on, and serialize the data, why are you abusing the view instead?). - Make it a rule that the framework never uses any classes not described in AMF spec to send it's RPC messages. The later, when neglected, imposes idiotic limitations on implementations and also caused conforming implementations to do a lot of hardcoded silly things, like, for example, automatically register an alias for ArrayCollection. This means that RemoteMessage class needs to be deprecated and replaced by just generic object, or array, other Remote* things which are sent over the wire need that too. This was a thoughtfulness design by Adobe targeting their proprietary data services, which makes no sense if we want to design a really functional and friendly product. Best. Oleg
