code, your proof and especially YOUR actionscript.
> Remoting is still a
> serverside deserialization of said webservice to native ActionScript
> whereas the webservices API is a clientside deserialization of the
> compressed web service soap.
That isn't entirely true. Yes, if you want to consume an actual web
service then you can use Flash Remoting to do it for you or you can
consume the web service directly assuming it is on the same server.
However, if you use Flash Remoting you might not need to consume a web
service at all.
Lets stop here. First of all: OBVIOUSLY MATT. We both know this
conversation was about Web Services API vs Flash Remoting Web Services.
No need to delve into convoluted semantics to prove you didn't know wtf
you're talking about before!
Now if you do actually use Flash Remoting to proxy a web service then
that web service is delivered to Flash via AMF; not SOAP. Thus, there
is a difference in performance on the server-side when you use Flash
Remoting to proxy a web service, but not on the client-side. Again
though, you can avoid that proxy step by no using Flash Remoting at all
and allow Flash to consume the web service directly. This means more
work on the client-side and less work on the server-side, which of
course should be the desired result. The only undesirable result is
long wait times on the client-side for large payloads. And again, AMF
produces smaller payloads than SOAP, but using HTTP compression with
SOAP fixes that issue too. So in the end, using SOAP and HTTP
compression means that you reduce the amount of server-side overhead,
have similar payload sizes, but increase the amount of client-side
overhead.
Once again, thanks for pointing out something that is glaringly obvious.
Guess what?! The sky is blue and you fall down less when you tie your
shoes too!
> The actionscript webservices api uses the
> built in xml classes in the flash player to parse the soap whereas the
> remoting gateway does this process for you.
Again, only when the gateway is proxing a web service. If it has direct
access to the class then there is no need to go through the web
services layer.
I know this. You know this. THAT WAS WHAT THE WHOLE THREAD WAS ABOUT.
> The http compression thing
> is completely unrelated to the respective implementations-- in other
> words it would benifit both but remoting would still ultimately be
> faster because it is a binary protocol.
Incorrect, you could use HTTP compression for both protocols, but the
amount of work on the server-side for Flash Remoting is simply higher,
so while the payload size of AMF would be reduced further it would be
insignificant since the protocol is already pretty small.
Incorrect?! INCORRECT?! What exactly is incorrect about that statement?!
You just repeated what I said!!!!!! You have never even personally coded
a single line of actionscript and you dare to say that my statement is
incorrect AFTER REPEATING WHAT I SAID IN DIFFERENT WORDS?! Amazing.
> Thats what I mean by common
> sense.... I suppose its common sense only if you understand that BOTH
a
> remoting server and the clientside webservices api can consume web
> services.
Again, it is not common sense because I understand how Flash Remoting
is actually implemented. Based on your comments you seem to have the
wrong understanding of how things work.
WTF?! That is just laughable. You're prior comments didn't demonstrate
anything but a rudimentary knowledge based on what macromedia's
marketing department has published and your own personal conclusions
drawn by what I could only describe as a beginners perspective to flash
development.
> You see I'm not contending that you should use webservices for
> your service layer. In fact I encourage it. I'm suggesting you consume
> those services with a remoting server if you want to enjoy a
> performance
> boost.
>
The only performance boost will be on the client-side, while you will
be occurring extra overhead on the server-side. If possible, it is
always better to place the overhead on the client-side, so scalability
is improved.
Yeah? I'd like to see one of your so called scalable client side flash
solutions. Flash falls flat on its face with anything reasonably complex
using the webservices api. You can't afford to do more than the bare
minimum with that client.
I am really offended by this response. I tried to be polite and not
point out that its especially obvious your experience with flash is
limited at best. I feel sorry for people like you, Matt. You are a very
insecure person to continue embarrassing yourself with weak arguments
and thinly veiled personal attacks.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
