You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2020/01/30 15:23:27 UTC
SharedObject should be in Storage lib
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
http://about.me/carlosrovira
Re: SharedObject should be in Storage lib
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
I'm a huge fan of AMF and I think is worth it to use with the current
SharedObject implementation done by Greg that already support AMF.
Of course others could use other options. As you say, we need to give
options.
El jue., 30 ene. 2020 a las 21:16, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> SharedObjectJSON sounds useful and a good alternative short of AMF. I'm
> sure you're not surprised to hear me say that we should give users choices
> depending on their needs. If they only need to store simple values,
> LocalStorage should work.
>
> I think we do have Strong-Type to JSON and back with the JSONReviver and
> friends in the Reflection SWC. I wonder if that would work with
> SharedObjectJSON.
>
> My 2 cents,
> -Alex
>
> On 1/30/20, 12:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> I think the browser can store objects already? Perhaps there is some
> way to
> do that, but I could not find anything for localStorage:
> ' The keys and the values are *always strings* (note that, as with
> objects,
> integer keys will be automatically converted to strings). '
>
> The LSO version is an emulation of Flash, so needs AMF to match
> behaviour.
> But it doesn't cover everything from the flash version.
>
> I made a separate version ' SharedObjectJSON' that uses JSON, and has
> no
> AMF dependency:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fframeworks%2Fprojects%2FMXRoyale%2Fsrc%2Fmain%2Froyale%2Fmx%2Fnet%2FSharedObjectJSON.as&data=02%7C01%7Caharui%40adobe.com%7C003f6fe86e174c93b69908d7a5bf6b4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160113867588036&sdata=b3EqPdXjr2x87PdM5Gg7NUy072eEMo%2FfpSc1NPvnkII%3D&reserved=0
> I'd also suggest the JSON version would be probably a good option for
> new
> projects that don't need strongly typed instances serialized.
>
> I used TDD for working on those. Both of the implementations are tested
> across swf and js, but I did not add tests to the CI build tests, and I
> can't remember all the reasons why now, but some tests required manual
> page
> refresh to test automatic flush etc.
>
>
>
> On Fri, Jan 31, 2020 at 8:42 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > 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" <ca...@apache.org>
> 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
> > (<ah...@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" <ha...@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
> > <ah...@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" <
> carlosrovira@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%7C003f6fe86e174c93b69908d7a5bf6b4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160113867598031&sdata=pWys%2B7bseu%2FfikqaQYOrqSS1CPmm4GpGO8q724g0wAs%3D&reserved=0
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C003f6fe86e174c93b69908d7a5bf6b4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160113867598031&sdata=pWys%2B7bseu%2FfikqaQYOrqSS1CPmm4GpGO8q724g0wAs%3D&reserved=0
> >
> >
> >
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: SharedObject should be in Storage lib
Posted by Alex Harui <ah...@adobe.com.INVALID>.
SharedObjectJSON sounds useful and a good alternative short of AMF. I'm sure you're not surprised to hear me say that we should give users choices depending on their needs. If they only need to store simple values, LocalStorage should work.
I think we do have Strong-Type to JSON and back with the JSONReviver and friends in the Reflection SWC. I wonder if that would work with SharedObjectJSON.
My 2 cents,
-Alex
On 1/30/20, 12:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
I think the browser can store objects already? Perhaps there is some way to
do that, but I could not find anything for localStorage:
' The keys and the values are *always strings* (note that, as with objects,
integer keys will be automatically converted to strings). '
The LSO version is an emulation of Flash, so needs AMF to match behaviour.
But it doesn't cover everything from the flash version.
I made a separate version ' SharedObjectJSON' that uses JSON, and has no
AMF dependency:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fframeworks%2Fprojects%2FMXRoyale%2Fsrc%2Fmain%2Froyale%2Fmx%2Fnet%2FSharedObjectJSON.as&data=02%7C01%7Caharui%40adobe.com%7C003f6fe86e174c93b69908d7a5bf6b4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160113867588036&sdata=b3EqPdXjr2x87PdM5Gg7NUy072eEMo%2FfpSc1NPvnkII%3D&reserved=0
I'd also suggest the JSON version would be probably a good option for new
projects that don't need strongly typed instances serialized.
I used TDD for working on those. Both of the implementations are tested
across swf and js, but I did not add tests to the CI build tests, and I
can't remember all the reasons why now, but some tests required manual page
refresh to test automatic flush etc.
On Fri, Jan 31, 2020 at 8:42 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> 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" <ca...@apache.org> 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
> (<ah...@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" <ha...@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
> <ah...@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" <ca...@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%7C003f6fe86e174c93b69908d7a5bf6b4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160113867598031&sdata=pWys%2B7bseu%2FfikqaQYOrqSS1CPmm4GpGO8q724g0wAs%3D&reserved=0
> > >
> > >
> >
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C003f6fe86e174c93b69908d7a5bf6b4c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160113867598031&sdata=pWys%2B7bseu%2FfikqaQYOrqSS1CPmm4GpGO8q724g0wAs%3D&reserved=0
>
>
>
Re: SharedObject should be in Storage lib
Posted by Greg Dove <gr...@gmail.com>.
I think the browser can store objects already? Perhaps there is some way to
do that, but I could not find anything for localStorage:
' The keys and the values are *always strings* (note that, as with objects,
integer keys will be automatically converted to strings). '
The LSO version is an emulation of Flash, so needs AMF to match behaviour.
But it doesn't cover everything from the flash version.
I made a separate version ' SharedObjectJSON' that uses JSON, and has no
AMF dependency:
https://github.com/apache/royale-asjs/blob/develop/frameworks/projects/MXRoyale/src/main/royale/mx/net/SharedObjectJSON.as
I'd also suggest the JSON version would be probably a good option for new
projects that don't need strongly typed instances serialized.
I used TDD for working on those. Both of the implementations are tested
across swf and js, but I did not add tests to the CI build tests, and I
can't remember all the reasons why now, but some tests required manual page
refresh to test automatic flush etc.
On Fri, Jan 31, 2020 at 8:42 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> 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" <ca...@apache.org> 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
> (<ah...@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" <ha...@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
> <ah...@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" <ca...@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%7Ccc1c807e7d384b049dda08d7a5bb7e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160097012240946&sdata=doNhtJw5LONR6bmpJcrzQVaERP2KV0ydXTFnjwFVHWU%3D&reserved=0
> > >
> > >
> >
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccc1c807e7d384b049dda08d7a5bb7e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160097012240946&sdata=doNhtJw5LONR6bmpJcrzQVaERP2KV0ydXTFnjwFVHWU%3D&reserved=0
>
>
>
Re: SharedObject should be in Storage lib
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ca...@apache.org> 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 (<ah...@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" <ha...@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 <ah...@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" <ca...@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%7Ccc1c807e7d384b049dda08d7a5bb7e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160097012240946&sdata=doNhtJw5LONR6bmpJcrzQVaERP2KV0ydXTFnjwFVHWU%3D&reserved=0
> >
> >
>
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccc1c807e7d384b049dda08d7a5bb7e22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160097012240946&sdata=doNhtJw5LONR6bmpJcrzQVaERP2KV0ydXTFnjwFVHWU%3D&reserved=0
Re: SharedObject should be in Storage lib
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ah...@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" <ha...@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 <ah...@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" <ca...@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
Re: SharedObject should be in Storage lib
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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" <ca...@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
>
>
Re: SharedObject should be in Storage lib
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ca...@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%7Cbfa96caa31234ac708a308d7a59867fc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637159946310702857&sdata=cpLMTk7VU52FRuEnIvb%2BWj2iXNJ4jWesre5tjD4GeMY%3D&reserved=0
>
>
Re: SharedObject should be in Storage lib
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ca...@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%7Cbfa96caa31234ac708a308d7a59867fc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637159946310702857&sdata=cpLMTk7VU52FRuEnIvb%2BWj2iXNJ4jWesre5tjD4GeMY%3D&reserved=0