> Try this, use a caching proxy in front of your web application and
> enable HTTP compression on the proxy. Compare the amount of bandwidth
> needed to what you think it would take with Flash. You will then learn
> what the pron industry already knows; HTTP compression pretty much
> eliminates the bandwidth issue.
>
> Now there are plenty of other reasons to use Flash over HTML, but
> bandwidth shouldn't be one of them.
>
>
What's the "pron" industry -- what do you use your computer for? %^)>
Actually. I have had just the opposite experience with Flash.
Flash uses web services or Flash Remoting to exchange data with the
server
The web service approach uses XML for the data exchange
Flash Remoting uses a proprietary binary format for the data exchange.
either of the above can often exceed the amount of data that would be
sent with a comparable html page fresh.
For example my application has a grid of 30 rows and 20 columns.
It is a quasi-real time application, that tries to consume data from
the host as fast as the host can supply it..
To refresh the data (only) with Flash Remoting (a dataGrid) takes
about 7-8 seconds. (I did not test using a web service because it
would take longer to transmit the more verbose (XML vs binary) data
format.
To refresh the entire page (data and format) with HTML takes about 4-6
seconds.
To refresh the entire data data grid only (html table) using a hidden
frame and _javascript_ takes about 3-5 seconds.
The other effect, is that the Flash Remoting solution ties up the
browser and utilizes 70% CPU (1 GHz G4 Powerbook). The hidden frame
approach utilizes 22% CPU. This, however may be due to my lack of
Flash expertise.
I didn't pursue the Flash remoting app any further. I will likely
experiment with a Flex Flash solution -- though prior threads suggest
that Flex 1.0 isn't as efficient as later releases will be.
HTH
Dick
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
