royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Re: Proxy method calls with RemoteObject
Date Mon, 15 Oct 2018 17:51:05 GMT
Hi Alex,

one thing I not understand is that this:

(service.echo as Operation).send();

should be

service.echo()

I think we're trying to remove "send()" and call directly "echo()"

I can go to your latest commits in both compiler and framework and try, but
don't understand the purpose, since calling with send() was what we had,
right?

Or maybe I'm missing something?

thanks

Carlos





El lun., 15 oct. 2018 a las 19:15, Alex Harui (<aharui@adobe.com.invalid>)
escribió:

> About 10 hours ago, after I cast the call to send in the example to be
> (service.echo as Operation).send() , it worked for me.
>
> I see you have made several changes to the example since.  Go back to
> where the example was about 10 hours ago, make that one change to
> service.echo.send() and it should work.  If other things are not working, I
> will look into them later.
>
> -Alex
>
> On 10/15/18, 10:11 AM, "Carlos Rovira" <carlosrovira@apache.org> wrote:
>
>     Hi Alex,
>
>     El lun., 15 oct. 2018 a las 18:54, Alex Harui
> (<aharui@adobe.com.invalid>)
>     escribió:
>
>     > There may be a couple of things affecting you.  One is that in the
> bug you
>     > reported, it looks like only the first RO is created and the others
> are not.
>     >
>
>     I 'm pretty sure the bug about mx:method is not present since I test
> in my
>     real project and in the example in our repo. In the first one I don't
> have
>     any mx:method and in the second I comment to test. Maybe we should
> comment
>     mx:method section in the example for now.
>
>
>     >
>     > Second, if you notice in the example, you'll see things like
> (service.echo
>     > as Operation).lastResult.  After adding support for callProperty,
> the calls
>     > now have to change to be either (service.echo as Operation).send() or
>     > service.echo().  The current syntax in the repo: service.echo.send()
> will
>     > result in an error because the compiler cannot know if the echo
> property on
>     > service is also a proxy or not.  The compiler currently guesses
> "yes" to
>     > make it easier for folks who have existing nested ObjectProxy data
> sets.
>     > So, Royale developers will have to do more "casting" with "as" than
> in
>     > Flash.
>     >
>
>     check the example since I change already to the new syntax to help you
> try
>     it. There's no "send()" anymore in the example in our repo.
>
>
>     >
>     > In Flash, the difference between proxy access and regular property
> access
>     > is handled in the runtime.  The JS runtimes do not do this.  The
> compiler
>     > could generate code that tests the class at runtime, but I think
> that will
>     > be too slow.
>     >
>     > Specific to RemoteObject, it might be possible to declare the JS
>     > RemoteObject to not be a Proxy and just Dynamic and have the
> constructor
>     > and getOperation call Object.defineProperty, but that is not a
> general case
>     > solution for Proxy.
>     >
>
>     Hi Alex, that's for me a bit far from my knowledge. I'm sure whatever
> you
>     get would be the best solution.
>     Currently mx:RO is broken and I'm working with the repo just before the
>     change localy to advance, hope you could take a look and see if you
> can fix
>     the issue.
>     If not, probably is better to comment the changes in the compiler (and
>     maybe in the framework?) to make it work again until we know how to
> fix it.
>
>     One thing I could test today (not related) in the meanwhile is if mx:RO
>     works with small messages on. The response is not, I think that is the
> AMF
>     serialization-deserialization. But I think this is not crucial, just
>     disabling it could be ok for now for most of folks out there (just
> knowing
>     that they need to configure that to false).
>
>     Thanks
>
>     Carlos
>
>
>     >
>     > My 2 cents,
>     > -Alex
>     >
>     > On 10/15/18, 4:51 AM, "Carlos Rovira" <carlosrovira@apache.org>
> wrote:
>     >
>     >     Hi Alex,
>     >
>     >     I added to the RO test example the CompressedRO test case
> commented to
>     > help
>     >     you find the problem.
>     >     I couldn't test like in net RO since now the entire example is
>     > failing, but
>     >     once the callProperty works for a normal case should help us to
> check
>     > if
>     >     the rest of RO works since it uses "convertParametersHandler"
>     >
>     >     I'll revert localy this changes in order to advance in my real
> world
>     > app in
>     >     the mean while
>     >
>     >     thanks
>     >
>     >
>     >
>     >     El lun., 15 oct. 2018 a las 13:40, Carlos Rovira (<
>     > carlosrovira@apache.org>)
>     >     escribió:
>     >
>     >     > Hi Alex,
>     >     >
>     >     > I found that even if I remove completely
> CompressedRemoteObject and
>     > use
>     >     > only normal mx:RemoteObject the error shows:
>     >     >
>     >     > [Error] TypeError: undefined is not an object (evaluating
>     >     > 'this.remoteObject.convertParametersHandler')
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > El lun., 15 oct. 2018 a las 13:00, Carlos Rovira (<
>     > carlosrovira@apache.org>)
>     >     > escribió:
>     >     >
>     >     >> Hi Alex,
>     >     >>
>     >     >> I'm finding a problem with callProperty. I'm using a
>     >     >> CompressedRemoteObjeect that uses two hooks in RemoteObject
> API
>     >     >>
>     >     >> public var convertParametersHandler:Function;
>     >     >>
>     >     >> and
>     >     >> public var convertResultHandler:Function;
>     >     >>
>     >     >> this makes the call fail with
>     >     >>
>     >     >> [Error] TypeError: undefined is not an object (evaluating
>     >     >> 'this.remoteObject.convertParametersHandler')
>     >     >> send (Operation.js:109)
>     >     >> callProperty (AbstractService.js:147:111)
>     >     >> dologin (LoginForm.js:181)
>     >     >> $EH1 (LoginForm.js:226)
>     >     >> (función anónima)
>     >     >> fireListener (events.js:744)
>     >     >> fireListenerOverride (HTMLElementWrapper.js:61)
>     >     >> handleBrowserEvent_ (events.js:870)
>     >     >> (función anónima) (events.js:289)
>     >     >>
>     >     >> So I guess the proxy is trying to proxy all even its own
> member
>     > functions
>     >     >> that should not be affected, makes this sense?
>     >     >>
>     >     >> thanks
>     >     >>
>     >     >>
>     >     >> El lun., 15 oct. 2018 a las 7:15, Alex Harui
>     > (<aharui@adobe.com.invalid>)
>     >     >> escribió:
>     >     >>
>     >     >>> I pushed changes to the compiler and framework to try to get
>     >     >>> callProperty to work.  I don't have a test case but give it
> a try
>     > and see
>     >     >>> what happens.
>     >     >>>
>     >     >>> If you compare the size of the output with and without
>     >     >>> -js-dynamic-access, you can see the theoretical savings of
> not
>     > using that
>     >     >>> option.  If that savings might matter, then it might be worth
>     > spending some
>     >     >>> time on fixing up the issues that -js-dynamic-access "works
>     > around".  But
>     >     >>> keep in mind that there probably isn't any way to grab all
> of the
>     >     >>> theoretical savings.  What we don’t know yet is where you'll
>     > actually end
>     >     >>> up.  It might even be true that -js-dynamic-access is more
> optimal.
>     >     >>>
>     >     >>> -Alex
>     >     >>>
>     >     >>> On 10/14/18, 3:02 PM, "Carlos Rovira" <
> carlosrovira@apache.org>
>     > wrote:
>     >     >>>
>     >     >>>     Hi Alex
>     >     >>>
>     >     >>>     El dom., 14 oct. 2018 a las 23:48, Alex Harui
>     >     >>> (<aharui@adobe.com.invalid>)
>     >     >>>     escribió:
>     >     >>>
>     >     >>>     > I got the resources working so I will look into
>     > Proxy.callProperty.
>     >     >>>     >
>     >     >>>     >
>     >     >>>     That's cool, I'm closing for today, I can try in some
> hours if
>     > you
>     >     >>> upload
>     >     >>>     some changes. Thanks
>     >     >>>
>     >     >>>
>     >     >>>     > The issue with js-dynamic-access isn't about MX
> RemoteObject
>     > vs
>     >     >>> Basic
>     >     >>>     > RemoteObject, it is whether, if we fixed places in
any
> of
>     > the code
>     >     >>> where
>     >     >>>     > minification breaks things, what the size/performance
>     > trade-off
>     >     >>> would be.
>     >     >>>     > Some variable names would be longer, but some other
> code
>     > might be
>     >     >>> more
>     >     >>>     > verbose as public vars are converted into
> getter/setters and
>     > have
>     >     >>> function
>     >     >>>     > call overhead.  I guess we'll find out when we get
> someone's
>     > app
>     >     >>> to the
>     >     >>>     > point where they are ready to get the production
> version to
>     > run.
>     >     >>>     >
>     >     >>>
>     >     >>>     Well, I'll need to have my app in production by the
> end/start
>     > of the
>     >     >>> year,
>     >     >>>     so we'll can check this with mine. For now it seems I
> need to
>     > left
>     >     >>> this
>     >     >>>     configuration or release version can pass the login (the
> mx RO
>     > call
>     >     >>> to the
>     >     >>>     server)
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>     >
>     >     >>>     > -Alex
>     >     >>>     >
>     >     >>>     > On 10/14/18, 2:23 PM, "Carlos Rovira" <
>     > carlosrovira@apache.org>
>     >     >>> wrote:
>     >     >>>     >
>     >     >>>     >     Hi Alex,
>     >     >>>     >
>     >     >>>     >     El dom., 14 oct. 2018 a las 18:32, Alex Harui
>     >     >>>     > (<aharui@adobe.com.invalid>)
>     >     >>>     >     escribió:
>     >     >>>     >
>     >     >>>     >     > Hi Carlos,
>     >     >>>     >     >
>     >     >>>     >     > JS proxy doesn't support callProperty yet.
 Feel
> free
>     > to add
>     >     >>> it, or
>     >     >>>     > I will
>     >     >>>     >     > after I finish up ResourceManager.
>     >     >>>     >     >
>     >     >>>     >
>     >     >>>     >     JS proxy is mx.utlis.ObjectProxy or you mean maybe
>     >     >>> AbstractService
>     >     >>>     >     callProperty?
>     >     >>>     >     I could take a look, but no promises since I don't
> know
>     >     >>> exactly how
>     >     >>>     > that
>     >     >>>     >     works. A little of guidance here could me make
get
> this
>     > done.
>     >     >>>     >
>     >     >>>     >
>     >     >>>     >     >
>     >     >>>     >     > I don't doubt that minification breaks lots
of
> things
>     > that
>     >     >>>     >     > js-dynamic-access fixes.  Hard to say how
much
> smaller
>     > your
>     >     >>> app
>     >     >>>     > would be if
>     >     >>>     >     > we fixed anough stuff without that option.
>     >     >>>     >     >
>     >     >>>     >     >
>     >     >>>     >     well, including mx:RemoteObject seems to increase
>     >     >>> significantly my
>     >     >>>     > current
>     >     >>>     >     app in release mode "mx" is 1'8mb while
>     > "org.apache.royale" is
>     >     >>>     > 1'8mb...but
>     >     >>>     >     is ok for me since I think is a normal payload
for
> the
>     > base of
>     >     >>> a normal
>     >     >>>     >     App, and MX RO here does an important role in
my
> case. So
>     >     >>> happy to pay
>     >     >>>     > the
>     >     >>>     >     price ;)
>     >     >>>     >
>     >     >>>     >
>     >     >>>     >
>     >     >>>     >     > -Alex
>     >     >>>     >     >
>     >     >>>     >     > --
>     >     >>>     >     > Carlos Rovira
>     >     >>>     >     >
>     >     >>>     >
>     >     >>>
>     >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cda71af12bb19486a275f08d632c13cae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752202865507448&amp;sdata=Q5xkLtRKwQF7q8%2FMQ3FIwsCca3pas9Z2izzOnTkZRwM%3D&amp;reserved=0
>     >     >>>     >     >
>     >     >>>     >     >
>     >     >>>     >     >
>     >     >>>     >     >
>     >     >>>     >
>     >     >>>     >
>     >     >>>     >
>     >     >>>
>     >     >>>     --
>     >     >>>     Carlos Rovira
>     >     >>>
>     >     >>>
>     >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cda71af12bb19486a275f08d632c13cae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752202865507448&amp;sdata=Q5xkLtRKwQF7q8%2FMQ3FIwsCca3pas9Z2izzOnTkZRwM%3D&amp;reserved=0
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>
>     >     >> --
>     >     >> Carlos Rovira
>     >     >>
>     >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cda71af12bb19486a275f08d632c13cae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752202865507448&amp;sdata=Q5xkLtRKwQF7q8%2FMQ3FIwsCca3pas9Z2izzOnTkZRwM%3D&amp;reserved=0
>     >     >>
>     >     >>
>     >     >
>     >     > --
>     >     > Carlos Rovira
>     >     >
>     >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cda71af12bb19486a275f08d632c13cae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752202865517453&amp;sdata=blbccJDK%2FFOKRsmppzC0NzithaJ%2FFrIJzQQV%2BKY8Ct4%3D&amp;reserved=0
>     >     >
>     >     >
>     >
>     >     --
>     >     Carlos Rovira
>     >
>     >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cda71af12bb19486a275f08d632c13cae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752202865517453&amp;sdata=blbccJDK%2FFOKRsmppzC0NzithaJ%2FFrIJzQQV%2BKY8Ct4%3D&amp;reserved=0
>     >
>     >
>     >
>
>     --
>     Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cda71af12bb19486a275f08d632c13cae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752202865517453&amp;sdata=blbccJDK%2FFOKRsmppzC0NzithaJ%2FFrIJzQQV%2BKY8Ct4%3D&amp;reserved=0
>
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message