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
>
©2004 Bill Arnold |
