Hi Carlos,

I probably don't understand your use case.  I would not recommend to new 
projects to use AMF to store data locally.  I think the browser can store 
objects already?  And I would think the difficulty of re-coding 
SharedObject.setProperty to LocalStorage.setItem would be worth the effort.

I must be missing something.
-Alex

On 1/30/20, 11:35 AM, "Carlos Rovira" <[email protected]> wrote:

    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 (<[email protected]>)
    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" <[email protected]> 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 <[email protected]>
    > 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" <[email protected]>
    > 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&amp;data=02%7C01%7Caharui%40adobe.com%7Ccc1c807e7d384b049dda08d7a5bb7e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160097012240946&amp;sdata=doNhtJw5LONR6bmpJcrzQVaERP2KV0ydXTFnjwFVHWU%3D&amp;reserved=0
    >     >
    >     >
    >
    >
    >
    >
    
    -- 
    Carlos Rovira
    
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Ccc1c807e7d384b049dda08d7a5bb7e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160097012240946&amp;sdata=doNhtJw5LONR6bmpJcrzQVaERP2KV0ydXTFnjwFVHWU%3D&amp;reserved=0
    

Reply via email to