incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <olegsivo...@gmail.com>
Subject Re: Actionscript workers and async locking?
Date Thu, 22 Mar 2012 09:34:47 GMT
I don't feel the async calls to networking API are a burden. I also have a
strong dislike of lock'ing from Java, so I don't feel particularly
enthusiastic about your example, but I can also see how this would be a
common thing to do. Think of what happens if your first call ends up in an
error? - will the lock be released? - if so, maybe the second part of the
code shouldn't be executed? Or maybe it should? and so on. Well, it is too
early to speculate about how the threading may look in AS3, but if I could
have a wish, I'd rather it be done in a way it is in Erlang, then Java
because it makes concurrency problems easier to spot / more similar to
events we already have in Flash.

If there is any improvement I wish for Flash networking API it would be
consistency. There is a handful of classes all having load() methods, but
impossible to abstract because the signature of the load() is different
(invariant types of context that is passed as a second argument). The
division of responsibilities of the said classes is lacking structure. Some
of them may be able to do the same thing, while not even being in any sort
of relationship one to another.
I'd be happy if Flash API followed more fairly the definitions of protocols
they implement and provide some sort of abstraction to that. S.t. for
example there would be an HTTP class that can connect, disconnect and
expose the stream, while connected, similarly, RTMP class etc, all either
inheriting or implementing the same superclass / interface.

I don't know what's the purpose of Flex RPC packages. So, I don't really
have an opinion on async tokens and such. That always seemed to me to be an
attempt of adding yet another layer of indirection on top of something that
already has few such layers.

Best.

Oleg

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