In recent applications using React/Webpack, I have seen defaults of using
base64 embedding of files less than 10k in size.
I guess the tradeoff is in between firing off several http requests for
small files vs embedding them is a less efficient format.
I think a similar strategy would work for Royale.
Thanks,
Om
On Thu, Jun 6, 2019, 3:32 AM Carlos Rovira <carlosrov...@apache.org> wrote:
> Hi,
>
> I think in the case of HTML, does not have sense to me the concept of Embed
> like in Flex. Maybe of SWF target or others (don't know if WebAsm could
> benefit from something like this)
> Maybe for HTML use something like Embed metadata, could just copy the
> assets to the resources folder to be available, since like Alex said, a
> request per asset is needed and making other kind of big file seems strange
> in this case (maybe not). Although we have solved the copying of assets in
> different ways through compiler for libraries and ANT/MAVEN automation in
> Application.
>
> for me this could be something to investigate in the future, but with low
> priority, since I think we still have bigger fish to fry
>
> just my 2...
>
>
> El mié., 5 jun. 2019 a las 18:07, Alex Harui (<aha...@adobe.com.invalid>)
> escribió:
>
> > Regarding embedded assets in Royale:
> >
> > There is no embedded asset support at this time because it is not obvious
> > to me it will be worth it. We need a volunteer to devise a strategy that
> > works and implement it.
> >
> > In Flex/Flash, my understanding is that folks embedded assets to save on
> > server requests for assets like images. That makes sense because, since
> a
> > SWF is a compressed binary and most assets are compressed binaries, you
> can
> > essentially append the assets to the SWF.
> >
> > However, for Royale in the browser, every implementation of "embedding"
> > I've seen seems to Base64 encode the asset, converting it to text and
> > increasing the number of bytes. And the resulting Base64 bytes may
> > deteriorate the gzip compression of the .html file.
> >
> > Flash also had frames in the SWF and assets could be embedded on later
> > frames allowing a download progress bar to show up before all of the rest
> > of the SWF is downloaded. I don't know what the equivalent for that is
> > without Flash.
> >
> > I believe another advantage of embedding in Flash was that the asset was
> > ready to be instantiated and placed on the display list right away. I'm
> > not clear that an embedded Base64 image can be used in an <img> tag and
> > prevent "popping" given that Royale generates the <img> tags dynamically.
> >
> > So, we need a volunteer to create some examples of how to use browser
> > embedding in dynamically generated <img> tags so we can see if there will
> > be any benefit or not. And if not, possibly explore other options, such
> as
> > delivering all assets in one true binary blob somehow.
> >
> > HTH,
> > -Alex
> >
> > On 6/5/19, 7:05 AM, "Frost, Andrew" <andrew.fr...@harman.com> wrote:
> >
> > Yes, me :-)
> >
> > I'm pushing Royale internally, I think it has a lot of promise -
> > although I still do find it a little frustrating at times internally! In
> > terms of what support you can give, the sorts of things you're already
> > doing are great, but yes it might mean we lean a little more on this
> > mailing list if we're facing tricky issues.
> >
> > We have one sales case in particular at the moment which has the
> > potential to be very big, we're hoping they move forwards with a proof of
> > concept project which would take a small part of their app and port this
> to
> > Royale. A few issues we've found so far from investigations:
> > - their flex code is embedding icons that are contained within a SWF.
> > Royale compiler didn't seem to like this, not sure whether it's just
> syntax
> > or whether we need to pull all the assets out (not a big job, we can
> > automate that..)
> > - they have binding using functions e.g.
> > text="{localizationHelper.getString('fieldName')}", which caused an issue
> > when generating the JavaScript code as the string-within-a-string seemed
> to
> > upset the parser. We can look at this later perhaps though..
> > - when we got it compiling, the main thing was with responsiveness
> > i.e. trying to get the app to resize and for all the internal elements to
> > then resize. We may use the MX emulation classes for this but it still
> > looked like more support is needed - although we only looked briefly at
> > this.
> >
> > Once those issues are sorted though, we would have one big task (to
> > recreate a very advanced data grid control that they'd developed in
> > Flex/Flash) and a lot of the rest - around the AS3 logic - should fall
> into
> > place! I'm hoping we can convince them to go with this solution..
> >
> >
> > thanks
> >
> > Andrew
> >
> >
> >
> > -----Original Message-----
> > From: Harbs [mailto:harbs.li...@gmail.com]
> > Sent: 04 June 2019 14:41
> > To: dev@royale.apache.org
> > Subject: [EXTERNAL] Re: AIR and Royale
> >
> > Well to start with: Does anyone know anyone working for them?
> >
> > I’d like to hear from them what it would take for them to push Royale
> > more.
> >
> > > On Jun 4, 2019, at 4:10 PM, Carlos Rovira <carlosrov...@apache.org
> >
> > wrote:
> > >
> > > Hi,
> > >
> > > what's the kind of support you're thinking ?
> > >
> > >
> > >
> > > El mar., 4 jun. 2019 a las 9:36, Piotr Zarzycki
> > > (<piotrzarzyck...@gmail.com>)
> > > escribió:
> > >
> > >> Hi Harbs,
> > >>
> > >> I was exactly think the same about that, so I'm keeping finger
> > >> crossed to that effort.
> > >>
> > >> Thanks,
> > >> Piotr
> > >>
> > >> wt., 4 cze 2019 o 09:34 Harbs <harbs.li...@gmail.com> napisał(a):
> > >>
> > >>> I just heard about this announcement.[1]
> > >>>
> > >>> I went over to the Harman site and was reading this page.[2]
> > >>>
> > >>> I was particularly struck by this statement:
> > >>>
> > >>> HARMAN’s offerings also include consultancy, support and
> migration
> > >>> services for companies looking to move their applications away
> > from
> > >>> Flash technologies over to HTML5 via solutions such as Angular,
> > >>> Apache Royale
> > >> and
> > >>> other JavaScript based frameworks.
> > >>>
> > >>>
> > >>> Considering that they mention Royale explicitly as the number 2
> > >> framework,
> > >>> I’m guessing they will be pushing Royale to a certain degree. We
> > >>> should probably look to support that effort.
> > >>>
> > >>> [1]
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2F3L9wbF4uCYccj7EQCUBeXbp7Vc%3Fu%3Dhttps&data=02%7C01%7Caharui%40adobe.com%7C1c133b6b710344d4bf3f08d6e9bed52a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953403171832330&sdata=XSKi6AAdovaj5CSqDxp4JKUXM%2Fu5uTzKYfJhrsWjO4s%3D&reserved=0
> > >>> %3A%2F%2Ftheblog.adobe.com%2Fthe-future-of-adobe-air%2F <
> > >>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2F3L9wbF4uCYccj7EQCUBeXbp7Vc%3Fu%3Dhttps%253A&data=02%7C01%7Caharui%40adobe.com%7C1c133b6b710344d4bf3f08d6e9bed52a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953403171842325&sdata=7Cp77z%2FW16Gf%2B9Q8P0%2Fs7qOBZdGYOh71F0bX%2BYLwXp8%3D&reserved=0
> > >>> %2F%2Ftheblog.adobe.com%2Fthe-future-of-adobe-air%2F>
> > >>> [2]
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2F36DC33RH3RXctPTGAK4XztY7Vc%3Fu%3Dhttps&data=02%7C01%7Caharui%40adobe.com%7C1c133b6b710344d4bf3f08d6e9bed52a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953403171842325&sdata=WmyyWadQQ1saSrBkTeuYmPiM0vDW49J3Lob%2BC7eejfg%3D&reserved=0
> > >>> %3A%2F%2Fservices.harman.com%2Fpartners%2Fadobe <
> > >>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2F36DC33RH3RXctPTGAK4XztY7Vc%3Fu%3Dhttps%253A&data=02%7C01%7Caharui%40adobe.com%7C1c133b6b710344d4bf3f08d6e9bed52a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953403171842325&sdata=JGO%2Fg99Iey8nKvQN5Hzd2EmXkle35QSllbc5UyDaj%2FE%3D&reserved=0
> > >>> %2F%2Fservices.harman.com%2Fpartners%2Fadobe>
> > >>
> > >>
> > >>
> > >> --
> > >>
> > >> Piotr Zarzycki
> > >>
> > >> Patreon:
> > >> *
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2F32dvoAS1WTaQP1E2yQmx5pn7Vc%3Fu%3Dhttps%253A&data=02%7C01%7Caharui%40adobe.com%7C1c133b6b710344d4bf3f08d6e9bed52a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953403171842325&sdata=%2FDiwRHFQCxdxO7pjeV85svwoRoI8nZmWpWBKDNgzr3w%3D&reserved=0
> > >> %2F%2Fwww.patreon.com%2Fpiotrzarzycki
> > >> <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2F32dvoAS1WTaQP1E2yQmx5pn7Vc%3Fu%3Dhttps%253A&data=02%7C01%7Caharui%40adobe.com%7C1c133b6b710344d4bf3f08d6e9bed52a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953403171842325&sdata=%2FDiwRHFQCxdxO7pjeV85svwoRoI8nZmWpWBKDNgzr3w%3D&reserved=0
> > >> %2F%2Fwww.patreon.com%2Fpiotrzarzycki>*
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2F3Peb7VMJWFagYLtTD2HSBGD7Vc%3Fu%3Dhttp%253A%252F&data=02%7C01%7Caharui%40adobe.com%7C1c133b6b710344d4bf3f08d6e9bed52a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953403171842325&sdata=PE5%2FahFsZHO5iuUE9pbP3jnax2KYXkxJBvBS%2Bfxb22Y%3D&reserved=0
> > > %2Fabout.me%2Fcarlosrovira
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
