RR as a browser plugin?

[Richard Gaskin]

Thomas McGrath III wrote:

> back in the day
> I used the SuperCard plugin in our corporate structure to role out
> quick easy stacks to departments that just wanted to view an update on
> info to our software (GUI and other info) in a simple way from a web
> browser. All they had to do was go to the company site and check it
> out.

But that meant the plugin was custom pre-installed.  Pre-installing a helper
app could be done just as simply.  And since SC had no built-in Internet
connectivity it's not like you had an alternative, the plugin was the only
way to deliver Internet-connected applets.

With a Rev-based helper app you have all the Internet connectivity you'd get
in a browser and more, and your choice of having greater security than a
browser by using Rev's secureMode, or unbridled power with it off.

> We found it very useful.
> Asking them to download a separate file was more than they wanted to do
> and more than I was allowed to ask of a Vice President.

No need for that:  your standalone helper app can download stacks on the
fly, just as a plugin would and as RevNet does now.

Stack files are stack files, the VM is the VM. You need the VM pre-installed
to run applets (stack files), so in practical terms it matters little
whether you have the VM in a browser's Plugins folder or outside of that
folder as a standalone.

> Also, a big difference is that downloading an app to a hard disk is
> different than downloading a temp file to a browser.
> I.E. temp files can be deleted by the browser but another scheme is
> needed to delete an app from a HD.
> This is important for propriatary stacks that we don't want staying on
> a users computer. (Yes, I know we can disable a stack after use etc)

This is where Rev has an advantage over SC:  in SC you must have a physical
project file to run it, whether in a standalone or the (now defunct) plugin.
But Rev can run stacks that exist just in memory, true download-n-go, as
RevNet does.

Again, I'm not saying a browser plugin is completely useless.  I'm merely
saying that it offers no significant real-world advantage you can't
capitalize on right now with the tools in hand today.


That's all I'm trying to accomplish here:  when you identify a need you can
go two ways to solve it, finding a way to satisfy that need today or
defining the problem in terms that require things beyond your control and
which may never actually come to pass.  Choosing the latter is less likely
to get results if doing the former can get the job done.

When a customer requests a feature it's too easy to fall into reactive mode,
where you run off and go implement the feature without asking how it will be
used, what problem it will solve.  That's the role of task analysis,
sometimes critical for arriving at optimal solutions.  Taking the "what" of
a customer request without asking for the "why" puts one at risk of rushing
feature afer feature to market, driving up development costs without ever
actually nailing the task.

If you have a customer asking for a plugin, ask them what they want to
accomplish.  I'll wager that after a good task analysis is done you can
satisfy their needs and then some right now, without needing to put
everything on hold waiting for someone else to give you a more limited
implementation of the same capabilities.

Should Rev decide to make a plugin down the road, your experience in
building working systems outside of the browser will empower you to make
experienced recommendations on how it gets done.  And in the meantime you
have clients with solved problems.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com