Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of olegsivokon@gmail.com
 designates 209.85.210.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <EB6F7A48D477254EAB8F675582F80CD726733DC9@DPSBS1.digitalprimates.local>
References: 
 <EB6F7A48D477254EAB8F675582F80CD726733C6E@DPSBS1.digitalprimates.local>
	<CBA35CE3.3EB8C%aharui@adobe.com>
	<CAJQBtg=NKBKftDYZ20KPY=rcaoBAYhQ04fFjfPiym96E41c2vw@mail.gmail.com>
	<EB6F7A48D477254EAB8F675582F80CD726733DC9@DPSBS1.digitalprimates.local>
Date: Thu, 5 Apr 2012 18:34:58 -0400
Message-ID: 
 <CAJQBtgmB48GYrt_UEDHMo7g=mRB+GWMwWcrBaA8L551V0kqhjA@mail.gmail.com>
Subject: Re: RFC - additional registerClassAlias
From: Left Right <olegsivokon@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae934048d63577b04bcf6265e

--14dae934048d63577b04bcf6265e
Content-Type: text/plain; charset=ISO-8859-1

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

--14dae934048d63577b04bcf6265e--