Even for IE10, there may be issues, see the "Known Issues" tab here [1]. Don't know if that affects AMF or not.
[1] http://caniuse.com/#search=Typed On 12/1/15, 11:25 AM, "Harbs" <harbs.li...@gmail.com> wrote: >BTW, here’s a good article on Typed Arrays. Specifically, see the section >on XMLHttpRequest2. > >http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ > >On Dec 1, 2015, at 9:11 PM, Harbs <harbs.li...@gmail.com> wrote: > >> Well, it seems to me that Typed Arrays is the right way to go about >>implementing ByteArray in JS.[1] >> >> IIUC, mimicking ByteArray is the hardest part of AMF. >> >> Of course, this means a minimum of IE10, but that might be OK… >> >> [1]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays >> >> On Dec 1, 2015, at 8:25 PM, Alex Harui <aha...@adobe.com> wrote: >> >>> >>> >>> On 12/1/15, 10:18 AM, "Christofer Dutz" <christofer.d...@c-ware.de> >>>wrote: >>> >>>> Well actually it sounded like: We had AMF support, but it didn't >>>>perfrom >>>> as well so we threw it away ... >>>> >>> >>> No, nobody I know has worked on it. I just have concerns about how >>>well >>> it will work. Of two implementations I found on the web, one had some >>> ties to GPL so I stopped looking, and the other was using getCharCode >>>to >>> implement ByteArray. Depending on how folks want to deal with older >>> browsers, we could try using Typed Arrays in the JS side. >>> >>> Other than cyclic object graphs, I don't understand why JSON and XML >>>can't >>> have decoders that convert to/from typed objects. That's how the SOAP >>> code works in regular Flex today. You might need custom serialization >>>for >>> cycles (at least in the early rounds). >>> >>> I understand that AMF had lower bandwidth, but I've heard that JSON >>>can be >>> compressed over the wire. >>> >>> -Alex >>> >>>> >>>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Harbs [mailto:harbs.li...@gmail.com] >>>> Gesendet: Dienstag, 1. Dezember 2015 18:56 >>>> An: dev@flex.apache.org >>>> Betreff: Re: [FLEXJS] AMF (was Re: AW: lib sprite flexjs,add >>>>graphics.as >>>> (canvas)) >>>> >>>> Instead of talking about throwing it away, why not discuss what is >>>>needed >>>> to implement AMF? It sounds to me like a great goal. >>>> >>>> I personally have never used AMF, so I have no idea. >>>> >>>> Harbs >>>> >>>> On Dec 1, 2015, at 7:47 PM, Christofer Dutz >>>><christofer.d...@c-ware.de> >>>> wrote: >>>> >>>>> There is no need for a amf to json converter. You would just use a >>>>> different serializer instead. >>>>> >>>>> What I'm worried about is that amf is way more powerful than json. >>>>>Let >>>>> me name some benefits: >>>>> - strongly typed >>>>> - able to serialize cyclic object graphs >>>>> - uses way less bandwidth >>>>> >>>>> Actually one of my talks at the last apachecon dealt with this >>>>>entirely. >>>>> >>>>> Giving up on this makes one of actionscripts benefits sort of >>>>>useless. >>>>> What's the good of being able to use strong types, if these get lost >>>>>on >>>>> the way from the server to the client? >>>>> >>>>> If we throw overboard all the good stuff, we'll be just one if the >>>>> other frameworks >>>>> >>>>> Chris >>>>> >>>>> >>>>> >>>>> Von meinem Samsung Galaxy Smartphone gesendet. >>>>> >>>>> >>>>> -------- Ursprüngliche Nachricht -------- >>>>> Von: Alex Harui <aha...@adobe.com> >>>>> Datum: 01.12.2015 18:29 (GMT+01:00) >>>>> An: dev@flex.apache.org >>>>> Betreff: [FLEXJS] AMF (was Re: AW: lib sprite flexjs,add graphics.as >>>>> (canvas)) >>>>> >>>>> Hi, >>>>> >>>>> Renaming this fork of the thread... >>>>> >>>>> Well, I have no doubts that AMF is quite popular, but I guess I >>>>>really >>>>> should have asked these questions: >>>>> >>>>> 1) If FlexJS didn't exist and you couldn't use FlashPlayer, how would >>>>> you get data from the server to client (and back again)? JSON, XML, >>>>> some other thing? The reason I haven't spent any energy on AMF for >>>>> FlexJS is because I think folks would have had to stop using AMF >>>>> anyway. Maybe there is an simple AMF-to-JSON module that folks could >>>>> implement on their servers to do the job so you don't have to rewrite >>>>> your server code. >>>>> 2) If FlexJS did have AMF but its performance was worse than using >>>>> JSON, would you still choose the slower AMF implementation? It isn't >>>>> clear that implementing AMF in JS is going to perform as well as >>>>> browser-native JSON or flash-native NetConnection. >>>>> 3) What is the minimum version of IE that needs to support this? >>>>> >>>>> Thanks, >>>>> -Alex >>>>> >>>>> On 12/1/15, 7:24 AM, "carlos.rov...@gmail.com on behalf of Carlos >>>>> Rovira" >>>>> <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> >>>>> wrote: >>>>> >>>>>> Hi Alex, >>>>>> >>>>>> AMF is "key" for Flex in IT ecosystem. you could make a Poll and, if >>>>>> most of people involved in Flex would fill it, you'll be surprised >>>>>>of >>>>>> the amount of AMF people is using to comunicate with server-side. >>>>>> >>>>>> So, this means, that for me and many others, the AMF is a requisite, >>>>>> (more even that Maven, that already is) to start prototyping and >>>>>> working with FlexJS in a day by day basis trying to change the >>>>>> traditional Flex 4.x layer for a FlexJS layer. >>>>>> >>>>>> HTTPService is a must, and is a good base, but it's used in any IT >>>>>> app about 5% of the times. People uses RemoteObject (and some times >>>>>> Web Services due to some request) as main RPCs >>>>>> >>>>>> For me AMF (and I think for many others) is the final wall to start >>>>>> investing time in our IT depts with FlexJS. >>>>>> >>>>>> Take into account that there are many server side business logic out >>>>>> there (Java, PHP, .NET, Ruby...) thats abstract all the things >>>>>> happening in the server from the Flex client, and is exposed to Flex >>>>>> through AMF - RemoteObjects. So having AMF in FlexJS seems the >>>>>> potential keypoint to start trying to change Flex 4.x for FlexJS, >>>>>> since you don't have the need to touch server side services. >>>>>> >>>>>> So, is a fact that AMF is key for FlexJS. >>>>>> >>>>>> Thanks for asking Alex >>>>>> >>>>>> Carlos >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2015-12-01 15:55 GMT+01:00 Vincent <vinc...@after24.net>: >>>>>> >>>>>>> +1, >>>>>>> All of our projects use AMF >>>>>>> >>>>>>> >>>>>>> Le 01/12/2015 15:52, Christofer Dutz a écrit : >>>>>>> >>>>>>>> Cause AMF is so much cooler than JSON ;-) >>>>>>>> >>>>>>>> I too would like to see AMF in FlexJS ... >>>>>>>> Actually if we drop AMF support there's no need for me to keep >>>>>>>> maintaining BlazeDS any longer. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> Von: Alex Harui <aha...@adobe.com> >>>>>>>> Gesendet: Dienstag, 1. Dezember 2015 15:32 >>>>>>>> An: dev@flex.apache.org >>>>>>>> Betreff: Re: lib sprite flexjs,add graphics.as (canvas) >>>>>>>> >>>>>>>> On 12/1/15, 5:22 AM, "carlos.rov...@gmail.com on behalf of Carlos >>>>>>>> Rovira" >>>>>>>> <carlos.rov...@gmail.com on behalf of >>>>>>>> carlos.rov...@codeoscopic.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I start to think the only big problem is now to get AMF comming >>>>>>>>>to >>>>>>>>> FlexJS. >>>>>>>>> >>>>>>>>> All frameworks (FlexJS, feathers, ...) out there are very cool, >>>>>>>>> but all lacks RPC APIs (RemoteObject, ...) >>>>>>>>> >>>>>>>>> And without that is impossible to propose a starter project in a >>>>>>>>> company or IT dept with FlexJS... >>>>>>>>> >>>>>>>> >>>>>>>> Hi Carlos, why AMF? FlexJS does have HTTPService. >>>>>>>> >>>>>>>> >>>>>>>> -Alex >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Carlos Rovira >>>>>> Director General >>>>>> M: +34 607 22 60 05 >>>>>> http://www.codeoscopic.com >>>>>> http://www.avant2.es >>>>>> >>>>>> >>>>>> Este mensaje se dirige exclusivamente a su destinatario y puede >>>>>> contener información privilegiada o confidencial. Si ha recibido >>>>>>este >>>>>> mensaje por error, le rogamos que nos lo comunique inmediatamente >>>>>>por >>>>>> esta misma vía y proceda a su destrucción. >>>>>> >>>>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le >>>>>> comunicamos que sus datos forman parte de un fichero cuyo >>>>>>responsable >>>>>> es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar >>>>>>la >>>>>> prestación del servicio o información solicitados, teniendo usted >>>>>> derecho de acceso, rectificación, cancelación y oposición de sus >>>>>> datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, >>>>>> 28036, Madrid con la documentación necesaria. >>>>> >>>> >>> >> >
