[thelist] Pet Market: SWF proven more efficient.

[Jon Hall]

Well I don't know if the version tested was secure or not, but I can say
that the pet store demo is definitely not secure. So the demo is definitely
not a real life situation as far as server resources go. SSL takes a lot
more resources then an unsecure connection.
Also the Demo introduces some usability concerns in the security area even
if all data is sent via SSL, and to me it's a big one.
Where is the little lock in the lower right hand corner?
Consumers are trained to look for it, and even if they don't notice, it's
one of the things that _every_ client notices. It's also a problem who's
solutions invalidates the entire Pet Store performance metrics in the real
world imho.
I can think of two solutions:
1: Feed the entire swf to the user on a secure connection.
2: Take the user to a seperate swf on a secure connection.

Number 1 requires more server horsepower, and number 2 requires more
bandwidth and more horsepower, but not as much horsepower as number 1.
Obviously real-world wasn't the point of this application, as is made clear
by the comments made in the Security section here:
http://www.macromedia.com/desdev/mx/blueprint/articles/makingpetmarket/makin
gpetmarket.html

However, the suggestions in those 4 paragraphs would make the application
take longer than two weeks to develop...and they are necessary in the real
world.

My conclusion? Pet store means nothing to people who live in the real world.
Looks cool though.

> SWF is more fun, _and_ more efficient.

I don't doubt that is true for some (and maybe me in the future), but for
someone who knows the DOM for every browser by heart, it's inefficient, and
therein lies the not fun part. And I can't view the freakin source!

----- Original Message -----
From: "John Dowdell" <jdowdell at macromedia.com>
To: <thelist at lists.evolt.org>
Sent: Wednesday, June 19, 2002 6:32 PM
Subject: [thelist] Pet Market: SWF proven more efficient.


> Howdy, I guess I'm throwing down a gauntlet here... can you pick holes in
> the performance metrics found for this set of web applications? 8)
>
> <http://www.macromedia.com/desdev/mx/blueprint/articles/performance.html>
>
> It's one of the few cases I've seen which has actually measured the server
> bandwidth costs and time-of-usage costs for roughly comparable web
> applications.
>
> (These aren't perfectly comparable web applications, because the
SWF-driven
> Pet Market adds photos and localizable external text to the application
> features, but despite that it still comes in at a lower overall cost.)
>
> Most of the advantages come from Pet Market completely separating the data
> from the presentation layer... it doesn't require the server generate and
> transfer a new display page after each user interaction, or to download
> complex text scripts for trivial client-side interactions. SWF is more
fun,
> _and_ more efficient.
>
> HTML is still great for documents, but SWF offers quantifiable advantages
> for applications. Anyone interested in taking the contrary position...?
;-)
>
>
>
> ----
>
> More info:
>
> Index of Pet Market articles:
> http://www.macromedia.com/desdev/mx/blueprint/
>
> Discussion group for the application itself:
> http://webforums.macromedia.com/richintapps/
>
> My overview of what the app does, and doesn't do:
> http://www.macromedia.com/desdev/jd_forum/jd010.html
>
> Discussion thread for Macromedia blueprints in general:
>
<http://webforums.macromedia.com/macromediafeedback/messageview.cfm?catid=22
> 0&threadid=37487>
>
>
>
> [Apologies for the multi-list post, but I think folks need to see this new
> stuff.]
>
>
> tx,
> jd
>
>
>
>
>
>
> --
> For unsubscribe and other options, including
> the Tip Harvester and archive of thelist go to:
> http://lists.evolt.org Workers of the Web, evolt !