flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Dove <greg.d...@gmail.com>
Subject Re: FlexJS question - ByteArray vs. BinaryData
Date Thu, 14 Jul 2016 06:33:10 GMT
Harbs and Alex, thanks for your explanations.

I guess 'drop-in' replacement is quite unrealistic. But I think if could be
closer to the IDataInput/IDataOutput, and given that ByteArray is a common
utility class in many libraries, particularly for low-level parsing of
various formats, the closer the better imo.

In my experience most ByteArray use seems to be mostly sequential reading
or writing which uses the flash class' read/write methods instead of array
access. So in terms of migration effort, swapping array access out wherever
it is used to the method-based getByteAt, setByteAt is not so bad.

Harbs, I picked up the recent updates from nightly and there is more there
than what I had for sure, but more to do I think - perhaps I can help - I
will try to work on this over the next day or so and share where I get to.
After using Flex for 8 years I am kinda struggling with my setup for
FlexJS, and I'm not sure if I can use monkey-patching  for checking the
additions I have in mind.... which I could do in the past with the regular
flex sdk.


cheers
Greg


On Wed, Jul 13, 2016 at 6:46 PM, Alex Harui <aharui@adobe.com> wrote:

>
>
> On 7/12/16, 3:57 PM, "Greg Dove" <greg.dove@gmail.com> wrote:
>
> >I have dipped my toes into FlexJS for the first time. I am evaluating
> >FlexJS for a migration away from Flex4/flash and figured I would try to
> >cross compile an isolated a3 library that is a core dependency for my
> >client's project.
> >
> >It seems there is no direct substitute for flash.utils.ByteArray on the js
> >side, The nearest I could find was org.apache.flex.utils.BinaryData which
> >seems to be a partial proxy implementation for ByteArray.
> >
> >BinaryData does not implement IDataInput and IDataOutput and therefore
> >cannot simply be used in place of the original ByteArray in arbitrary
> >code.
> >
> >Is this intentional? Or is this WIP, with a plan to get to the original
> >interfaces? Or am I looking in the wrong place for what I am trying to do
> >(entirely possible!).
>
> IMO, FlexJS is a WIP, but there is no "plan" per-se.
>
> Unlike Flex, FlexJS is intended to support multiple component sets.  The
> Basic set we have released so far is meant to thinly wrap Browser/HTML/JS
> APIs so that when you compose an application, the result has as little
> overhead as possible when compared to writing an HTML/JS app directly in
> JS.  It isn't a goal for these components to emulate Flash.  Instead, the
> SWF versions of those components are trying to emulate the browser.
>
> There is an experiment under way to try to see how hard it would be to
> make a component set that supports most (but not all) Flex APIs.  We
> received several opinions that the Basic set is too big of a migration
> step for existing Flex code bases.  Flex is already heavy so making a
> heavy component set that lowers migration pain by spending code on
> emulating more of Flex in the browser might be viable.  This component set
> is a ton of work and isn't a top priority on my list right now and could
> use more volunteers to help.
>
> ByteArray isn't even a Flex API.  But it is often used so I suppose a
> component set that emulates Flex will likely have to support most of
> ByteArray.  The Basic set is supposed to be pay-as-you-go and use plugins
> for additional functionality, so IDataInput/IDataOutput might be replaced
> by plug-ins that support similar APIs.
>
> But really, what actually happens is often up to the person that codes it.
>  We don't have resources to mark every API as needing implementation, and
> since we want to make many implementations as plugins, the API may not be
> the same anyway, so we just need folks to jump in and deal with holes in
> the documentation and code and help make things better for the next person
> who jumps in.
>
> HTH,
> -Alex
>
>

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