IMO Flex solves a very particular problem, which is implementing the GUI. The only two integration problems that it solves are 1. communication with the server through HTTP/AMF/RTMP. 2. communication with the HTML host through BrowserManager. The latter being of doubtable usefulness to me given that most of the time you end up implementing your own deep linking strategies because it does not meet your particular needs and also because it does not have an AIR counterpart, which leaves the feature as kind of "incomplete".
I see Flex as a "host" agnostinc GUI toolkit. Any integration which is not cross platform/browser/device would have to be extracted and implemented as an opt-in separate library that enhances Flex functionality in that given area. Other than that, I think that having to deal with (in this context) dependencies with browser vendor related issues ( potential cross browser incompatibilities and all that ) is something that could affect the natural release cycle of the the SDK itself. Cheers On Tue, Jul 10, 2012 at 10:46 PM, Om <bigosma...@gmail.com> wrote: > On Tue, Jul 10, 2012 at 12:40 AM, Joan Llenas Masó <j...@garnet.io> wrote: > > > I like the idea of leveraging HTML5, > > I'm not sure whether it should be part of the SDK though.. > > It sounds more like a good 3rd party library to me. > > Which makes me wonder whether we need to create some sort of "official > Flex > > SDK extensions" to make room for all these really nice to have additions. > > > > Cheers! > > > > > > > If I may ask, why do you think it should not be part of the SDK? If we can > provide a robust abstraction layer - for ex. IndexedDB for browsers/SQLLite > for AIR, I think that would be a fantastic addition to Flex. Or at least > provide a least common denominator like storing and retrieving just > key/value pairs. Imagine writing applications using Flex and being able to > write to a local database without having to worry about the underlying > technology/platform. I am pretty sure that would be a very welcome feature > for our end users. > > Anyways, I dont think I have a very strong argument because I dont have any > code to show right now. Let me build the APIs and post it withe code > samples first :-) > > Thanks, > Om >
