Bill,
Thanks for helping me think through my design. Your common sense
observations about my paranoia over application internal security may
allow me to simplify my plugin architecture. I going to sleep on your
comments and see if they still make sense in the morning.
Regarding EXECSCRIPT, please make sure you see my follow-up post on how
EXECSCRIPT really works. In my original post I mistakenly believed that
EXECSCRIPT() code was isolated from the calling application. This is
_NOT_ the case.
Malcolm
----- Original message -----
From: "Bill Arnold" <bill /at/ wjarnold DO.T com>
To: profoxtech@leafe.com
Date: Sat, 30 Oct 2004 22:26:40 -0400
Subject: RE: Application design to accept plugins
Hi Malcolm,
I've done this using the COMPILE approach, but your post got me to look
at
EXECSCRIPT again, and it makes me wonder why I went with COMPILE in the
first place. COMPILE is relatively messy because it leaves Fop's on the
users machine, where EXECSCRIPT just runs the code directly. Much
better. (I
keep user code in memo fields, btw)
The down side is, as you mention, giving the user/programmer access to
the
app's environment. I wouldn't be too concerned over the exposure to
knowledge of your app's internals, because, let's face it, the VFP code
can
be decompiled. That's a licensing/legal thing. The other concern would
be
potential damage this person could cause to the application. Again, the
user
can access the app's data files externally anyway. So, I'd make the case
that the exposures are there anyway (unless, of course, you go through
great
measures to address these issues as a general matter).
In terms of exposing the application to damage, one thing to do is to
beef
up recovery mechanics throughout your system, which is a never-ending
thing,
but overall important anyway. One thing I do is install a SAMPLES.ZIP
file
that contains default copies of key files used by the app (or, it could
be
available on the web), and offer it to the user as a last resort (i.e.
when
user has taken no backups - even though you've given them a simple
command
button to push <s>) to getting out of any trouble should the worst
happen.
With giving the user this ability, obviously be very important to
emphasize
the importance of backups and fallback plans, and the cost to them if
something goes really wrong and you have to come in to fix it.
But, overall, I really like the idea of giving the user this ability.
While
I've tried to give the user as many customization options as possible
(define their own 'extension' fields to tables, choose their own command
buttons, tab pages; menu customization on the list, but not done), I
think
the more options the users have, the better. I say this because I've
never
had two customers who wanted the same thing. They all want things their
way.
So, I say give it to them!
I think this is another area where VFP really rocks!
Bill
> I would like to open up an application so that 3rd parties
> can _SAFELY_ add additional functionality without access to
> my application's source code or internal runtime environment
> (work areas, variables, SET values, etc). My application
> already has hook points that could be enhanced to check for
> plugins and communicate with them if present.
>
> My strawman ideas:
>
> 1. Define a simple XML syntax for communication between my
> application and plugins.
>
> 2. By default, use a low level file for passing messages.
>
> 3. Optionally define an expected COM interface that my
> application would use to "bind" to external plugins. The
> downside to a COM interface is that users would have to
> install plugins as COM components and most of my customers
> run in locked down environments that will not allow them to
> install COM or ActiveX components.
>
> I'm also thinking of allowing users to write plugins in VFP
> source code and use EXECSCRIPT() to execute their code. My
> understanding is that
> EXECSCRIPT() code does _NOT_ have any access to the calling
> application's work areas, variables, SET values, etc) and so
> could safely be used as a type of "external scripting
> language". I'm choosing
> EXECSCRIPT() vs. COMPILE because any code run via the COMPILE
> command will have access to my application's internal environment.
>
> Feedback, suggestions, warnings, etc? Fire away!
>
> Thanks,
> Malcolm
>
[excessive quoting removed by server]
©2004 Malcolm Greene |
