flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <olegsivo...@gmail.com>
Subject Re: RFC - additional registerClassAlias
Date Sun, 08 Apr 2012 11:52:44 GMT
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

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
- 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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message