Well, the whole thing about how serialization in Flash works is moot... but it's not anything that we could help, even if we wanted to very much.
Probably, it should be made clear that this is not just serialization into some amorphous format, especially because JavaScript, if we will ever get there, will need it's own AMF implementation (which is actually easy!). There are other problems current model doesn't solve (because it was blind-copied from Java, and it just works bad there too). Anyway, recursive serialization of IExternalizables is a pain - you can't really do this using just the built-in API, chances are, that if that is what you need, you will write AMF serializer on your own, in AS3 :) Funny, eh? Besides, if you have a more complex object to serialize, where several IExternalizables plug in, you won't be able to take advantage of AMF format because it, when writing these objects is not aware of the context, where they will be placed, and it will not "optimize" the parcel after the last write. Essentially, in order to have effective AMF serializer, the existing native API are lacking. You _always_ need the context, where you write your objects. Always as in any non-trivial situation. Alternatively, you can do it in two layers - similarly to how tar is usually used with gzip (tar creates single piece file, while gzip compresses the whole thing). Present AMF serialization model in this light resembles that of zip, where both the archiving and compressing done by single program file by file causing bad reuse rate for when you are compressing more then one file. Now, there's another aspect. Framework prescribes serializing views! Against all odds you serialize the collection's view (and you forget about how it was sorted and the bookmarks and all that). This is a bad practice. No one, ever, should have serialized ArrayCollection, ObjectProxy and other *abominations* :). Yet another problem is with [RemoteClass] meta. It - makes the process almost impossible to debug (w/o in-depth knowledge of the framework templates you wouldn't know where the code registering alias goes). This created a whole lot of mythology and superstitions. - you can't control when it happens (effectively, you don't even know, but assume it's before the application even starts - which is of course wrong). All that said - I'd be for making the mechanism more transparent, if at all taking any steps in order to build on top of what built-in functions have to offer. But if I was to design the API for this, it would be something like: AMFContext.createContext() :: AMFContext; AMFContext.registerAlias(Class, "alias") :: void; AMFContext.append(object) :: void; AMFContext.onSerialize(function(Class), data) :: void; AMFContext.onDeserialize(function(Class), data) :: void; AMFContext.flush() :: ByteArray; So, while we add more classes *sigh*, we could actually reduce the size it takes on the wire, when serializing everything in one go, instead of doing it item at once. But in this way we avoid global handling, security problems with who registers alias where and so on... Well, just brainstorming :) Best. Oleg
