Hi Alex, I tried this and reverted the commit since it has more things to be considered. LSO can be considered part of the AMF set of code, and depends on AMF classes that are currently in MXRoyale, for that reason Greg created there and not in Storage. These classes will need to be refactored out of MXRoyale as we already planned months ago. Right now we need to exclude CSS from MXRoyale, to avoid mess with other CSS. Another reason for me (and maven users) is to avoid have APIs that you don't need (a thing that I know is not very important for you or others that could prefer all APIs at hand, but that I care for).
A side from that I think MXRoyale needs to focus on MX and SparkRoyale on Spark, as well someday hope I can create MXRPC that have all RPC, HTTPService, LSO,... If you remember we already talked about this months ago, and I tried, but was more time at that moment, and needed to left the work in a branch. LSO is a flash class and has the benefits of use AMF encoding and decoding, what I think is a cool feature to consider (many not for others) and there's no MX counterpart, is now part of the emulation due to the AMF issue, but will need to be in MXRPC lib. I tried LSO for the TodoMVC.com example I'm working on (since is part of the specifications in the todomvc.com site), and did not want to add to the pom MXRoyale to not confuse new comers, anyway, there's no way for now, and we need to left as is. Anyway I'm very satisfied with the example since we can see Royale is now very robust in many aspects :). Hope to finish it soon and share. Thanks Carlos El jue., 30 ene. 2020 a las 18:28, Alex Harui (<aha...@adobe.com.invalid>) escribió: > I don't know if it would be more "general" since it would be > Flash-specific, but re-use of code from Storage is always a great goal. > The MXRoyale components re-use quite a bit of code from Basic. > > Taking a quick look at the ASDoc, SharedObject offers both Local and > Remote flavors and a "connect(NetConnection)" API which is probably not > needed for locally storing some data and would drag in dependencies for > NetConnection emulation from MXRoyale. Meanwhile, > org.apache.royale.storage.LocalStorage seems to have a similar API to the > subset of SharedObject that folks would actually use for a local > SharedObject, so the MXRoyale emulation of SharedObject would probably > subclass or wrap LocalStorage. > > Of course, I could be wrong... > -Alex > > On 1/30/20, 9:05 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > Possibly a MX version with Flash APIs should use a more general > version from Storage? > > > On Jan 30, 2020, at 5:45 PM, Alex Harui <aha...@adobe.com.INVALID> > wrote: > > > > I don't know LSO or the Storage SWC that well, but there is some > sort of LocalStorageProvider.as file already in Storage. > > > > IMO, if you are planning to 100% emulate the Flash LSO, that should > go in MXRoyale. A more platform-independent API for local storage should > go in Storage. I don't know what is already there. > > > > My 2 cents, > > -Alex > > > > On 1/30/20, 7:23 AM, "Carlos Rovira" <carlosrov...@apache.org> > wrote: > > > > Hi, > > > > I was searching for some Flex counter part to the LSO classes in > MXRoyale > > but didn't find anything. > > So if nobody opposite I'll move to the Storage library that seems > its > > natural place. > > > > Thanks > > > > -- > > Carlos Rovira > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca79b7a12ace243a1de7008d7a5a69466%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160007186377921&sdata=lNxcjfaUNG%2BbuqsOk4O3KDm0e9fmoZPmZF72yVBmOw8%3D&reserved=0 > > > > > > > > -- Carlos Rovira http://about.me/carlosrovira
