[Zope-dev] Task, Job or Operation?

jpenny@universal-fasteners.com jpenny@universal-fasteners.com
Mon, 23 Oct 2000 14:56:43 -0400


On Mon, Oct 23, 2000 at 11:08:14AM +0100, Chris Withers wrote:
> jpenny@universal-fasteners.com wrote:
> > I can see four potential properties that one could want to emphasize
> > about a python method.
> > 
> > 1) It is safer (to the Zope server) than a python external method.
> > 2) It safer to the end user than a JavaScript (it never touches the client).
> > 3) It uses python, and not something else as its implementation technique.
> > 4) In OO terms, it is not really a Method.
> 
> Good points :-)
> 
> > Hence the preference for Safe in the name.  Even a newbie ought not to
> > be able to cut himself too badly on a python method.
> 
> I dunno...
> 
> > descriptive.  Widget has technical meaning.  Perhaps task or job are
> > suitable, as in
> > Safe Python Task
> > Safe Python Job
> 
> > Then external methods, which are often also not methods, can become
> > Flexible Python Task
> 
> Well, felxible doesn't really explain a lot. Filesystem is probably the
> most explicit.
> 
> I dunno, I actually like Jeff's suggestion of Operation giving you:
> 
> PythonMethod    ->     Python Operation
> External Method ->     Filesystem Python Operation
> 
> The same could also apply to DTML and Perl Methods. A nice side effect
> is that you could have Filesystem DTML Operation replace those horribly
> named HTML File objects you get when use grab your DTML out of .dtml
> files on disk. Especially as they bypass all known security ;-)

OK, here is why I used Safe/Flexible.  I still think that it is important
to give newbies guidance as to which to choose.  Because of the restrictions
(no import, no _ variables, etc.) that Python Methods provide, it is
far safer for a newbie to tackle Python Methods, and discarding them only 
when they are incapable of doing the needed operation.

It is simply true that python methods ARE safer than external methods and
ARE to be prefered if they have enough power.

Hence the strong preference for Safe in the term.

Now, what are things that stand in distinction to safe.  One set is
unsecure, risky, dangerous.  No sane company is going to call a thing
Dangerous Python Operation (even if true).  So that set of associations
is out.

Another set of anti-associations is unprotected, open, unguarded.  While this
set is better, there are still too many connotations of danger.

Another way of looking at it is that safe is similar to restricted (restrictions
are enforced to maintain safety).  Here the opposites are unrestricted, 
powerful, flexible.

I don't like powerful here.  It will encourage a newbie to skip the safe
version entirely (what newbie doesn't want unlimited power?).  Turbo,
and supercharged imply extra speed, which I don't believe to be significant.
Unrestricted has a double negative problem.  Hence something like flexible.

I really don't like Filesystem here.  It is true.  But, it provides the
newbie zero guidance.  Why should one use a Python Operation rather than
a Filesystem Python Operation?  The answer is nowhere to be found in the
name (unless you count that the name is shorter!).

I rather like the Zopelet suggestion.  I would like to retain Safe/(some
anti-association) in the name.  This would give something like:

Safe Python Zopelet
Flexible Python Zopelet  or Power Python Zopelet, or Filesystem Python Zopelet
or something else.

This is going on too long, but 2 more thoughts.

The Safe version should appear in the pulldown before the corresponding
Flexible/Power/Filesystem version.  These lists are read by Euro-language
readers fro top down and we want them to see the Safe version first.

Another set of terms for this might be chosen from magick terminology,
i.e. spell, incantation, cantrip.  Then we could have
grimoire/formula/cantrip.  Such a nice set of terms!

> 
> cheers,
> 
> Chris