flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: FlexJS question - ByteArray vs. BinaryData
Date Mon, 18 Jul 2016 07:46:27 GMT
Pull requests are easiest.

The first pull request is the hardest (setting up a fork and what-have-you), but once you
do it once, it’s really easy the next time around.

Here’s my recommended process for doing pull requests:
1. On Github, fork the repo.[1]
2. Add an additional remote to your git repo and specify the url of your fork. I like to use
SourceTree and adding additonal remotes can be done there by selecting “Reposiotory >
Repository Settings…” and then clicking “Add”. Specify your fork URL and call it whatever
you want (i.e. fork or something smart).
3. Commit your changes and push them to your fork.
4. The go to Github and create a new pull request.[2]



On Jul 18, 2016, at 8:03 AM, Greg Dove <greg.dove@gmail.com> wrote:

> Harbs,
> FYI I have made progress on this and expect I will have something to share
> with you in a couple of days.
> What is your preferred way to submit a patch for review? Is it easiest to
> make a pull request against the github mirror? (I use git a lot, but have
> somehow avoided making a pull request for anything so far, so this would be
> something new for me!). Otherwise I can link to or send patch files etc -
> whatever works best.
> cheers,
> Greg
> On Thu, Jul 14, 2016 at 9:38 PM, Harbs <harbs.lists@gmail.com> wrote:
>> FYI, I just added an “array” getter which returns the underlying array of
>> bytes. The exact type is different on the different platforms.
>> Alex, I tried to make the type “TypedArray” instead of “Uint8Array” on the
>> JS side, but TypedArray was not recognized for some reason. Any ideas on
>> why that might be?
>> Harbs
>> On Jul 14, 2016, at 9:33 AM, Greg Dove <greg.dove@gmail.com> wrote:
>>> 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
>>>>> 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

View raw message