Re: [Zope-dev] Task, Job or Operation?
Just a few comments to throw into the naming convention. Any name chosen will require educating the user as to it's definition. Some names are already defined in other spaces. Some of which are heavily overloaded. There is also discussion as to the accuracy of various names in the context of the usage within Zope. It is apparent the choice isn't clear and easy. As Michel has posted that a vote will occur in the near future a determination will be made. Currently one of the terms in usage is External Methods. From my understanding of the future direction of the Python Methods (restricted and unrestricted) the term External will not be accurate as the code will be within the ZODB and the differentiation will be in the capability of the method. Due to this I think the usage of External not be included in the name. Likewise Internal. Regarding Safe and Power. I have no major problems with Safe, however I thing Power brings along a lot of connotations or implications which may or may not be accurate concerning the abilities of Safe. As others have noted why choose Safe when you can use Power. Why, will have to be a part of the educational process. However proper perspective and understanding can start by not using Power in the name. I believe Power is not the right choice. Unsafe has also been proposed. I do not like this either because it is not accurate. Simply because something dangerous, foolish or stupid can be done using this method type does not mean it will be. Are we to label all objects "unsafe" simply because of the capacity of harm? Safety is in the hands of the programer. You cannot stop someone with the capability from doing something harmful if they choose. I would prefer the term Unrestricted or something similar. It simply denotes capabilities without implying it is dangerous. It isn't dangerous, it can be used dangerously, there is a difference. It is like many tools which can be used or abused. Hope this helps. Jimmie Houchin ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Task, Job or Operation?
Some name suggestions - block has been suggested before What about - ZopeCodeBlock from there: Internal Python ZopeCodeBlock External Python ZopeCodeBlock Internal Perl ZopeCodeBlock Safe Python ZopeCodeBlock Alternatively something like ZopeBrainBlock might be considered, though I do not particularly like it my 2 cents Rik ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Task, Job or Operation?
Pylet? Perlet? Xlet? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Task, Job or Operation?
On Mon, Oct 23, 2000 at 03:07:25PM -0700, James Johnson wrote: > Is there a Wiki or some other starting point for this thread. As a > newbie I like safe vs power over anything else. I also understand > that with using anything in a power mode can be risky for a newbie. > It's nice to know that I can start out learning in a safe mode and > then graduate to a power mode after learning more. Is there a > ZopeScript and why not? Safe ZopeScript can be written in using other > scripting languages. Zopelet imho is not as marketable as ZopeScript. OK, this is the problem. There are several ways of writing executable code available to other objects in Zope. One is the Python Method. It is available from http://www.zope.org/Members/4am/PythonMethod >From 4am's page: PythonMethods will not allow assignment to an attribute, element, or slice. No "del" is allowed. Names starting with "_" are not accessible. Import is controlled. Globals all live in a private namespace. There is a proposal to call this construct a Zope Script. And your message is exactly the ammunition I wanted. Thanks! The other way to script in python is currently called an External Method. Since perl is being added as a Zope scripting option, this will clearly have to be renamed, as well. External Methods have none of the restrictions of PythonMethods. This makes it quite easy to escape all Zope security, to crash Zope, and to do other nasty things. Needless to say, Zope hosting sites do not generally provide External Methods. There is no ZopeScript, and probably never will be. What would ZopeScript do? Would it be a construct like JavaScript that was executed on the client's computer? If so, every browser vendor would have to support it. This is unlikely, to say the least. Is it server side? Then DTML, PythonMethods (to be renamed), PerlMethods (which don't exist yet), External (Python) Methods, External Perl Methods (which also don't exist yet) give plenty of scripting options, without the need for another language. It is not at all clear that Safe scripting methods (in the strong sense meant here, meaning that it can neither damage the client nor the server), can be written in languages other than Python (I have heard some doubts expressed about perl). And, there is generally no need to "graduate" to external (power) methods. You only need to use an external method when you need a module not imported by Zope (not available through the _ namespace). So, you have written several things in your message that really bolster my dislike for both zope script and power as terms. 1) You have gone from the word Zope Script to a separate language ZopeScript in a single bound. 2) You have assumed that you will want to "graduate" from Safe Methods to "Power" Methods (You don't, external methods are last resort options). 3) "Power" methods don't require a lot more learning than Safe Methods. You have to learn what modules are available, but you are using the same language in either case! Maybe my suggeston of flexible is to weak. Maybe they should be Escape Hatch Python Operations (Escape Hatch Python Zopelets)! > When you call it operation, method, or function it takes it away > from it's context. This is zope specific right? Excuse me while I > use safe ZopeScriptPython or power ZopeScriptPerl. Not really Zope specific in the sense you mean. It is an object (not in the OO meaning) that can be called from a Zope site. But the language is pure Python (perl), with no modifications, and usually can be snipped and executed outside of Zope. > > > Get your Free E-mail at http://tacoma.zzn.com > > Get your own Web-Based E-mail Service at http://www.zzn.com > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Task, Job or Operation?
Is there a Wiki or some other starting point for this thread. As a newbie I like safe vs power over anything else. I also understand that with using anything in a power mode can be risky for a newbie. It's nice to know that I can start out learning in a safe mode and then graduate to a power mode after learning more. Is there a ZopeScript and why not? Safe ZopeScript can be written in using other scripting languages. Zopelet imho is not as marketable as ZopeScript. When you call it operation, method, or function it takes it away from it's context. This is zope specific right? Excuse me while I use safe ZopeScriptPython or power ZopeScriptPerl. Get your Free E-mail at http://tacoma.zzn.com Get your own Web-Based E-mail Service at http://www.zzn.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Task, Job or Operation?
Sorry for the duplicate post, forgot the subject. :) Hi Name Hunters, My problem with Zopelet is that it already has a meaning, at least to me. Looking down the road, not nearly as far as one might imagine, let's see where we may be heading. Think about minimal Zope instances running on Palm Gizmos, Cell Phones, whatever, a sort of personal ZEOClient, that enables offline or intermitent access to Zope Applications (e.g. WorldPilot). That's a Zopelet to me, a "little Zope". As for the other suggestions, "Op" sounds right to me. An Operation, or an Operative carrying out some work on behalf of the caller. Python Op, Perl Op, XSLT Op. It's short too! Also, Safe is clear, and easy to grasp, since most folks are aware how critical security can be. As for Flexible vs. UnSafe, how about "Direct", as in, "running directly from the file system"?. The term implies a trade-off of power for some degree of insecurity, at least to the initiated. Newbies should be warned away if they don't get the connotation. This leads to: Direct Python Op, etc. Later, Jerry S. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Task, Job or Operation?
On Mon, Oct 23, 2000 at 11:08:14AM +0100, Chris Withers wrote: > [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Task, Job or Operation?
Huh. We're looking for something neutral, to connote code that runs in zope to do some business logic or similar effect. It should distinguish the language used to express the logic - perl vs python vs xslt, etc. I hate "script", but it occurs to me that the "-let" convention may be useful: Python Zopelet Perl Zopelet XSLT Zopelet Zope-specific, runs on the server, shows the implementation language, won't be confused with non-remotely-editable functions, methods, scripts, code in general. This is the first one with which i'm comfortable - but i may well have missed something. Ken [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Task, Job or Operation?
[EMAIL PROTECTED] 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 Nah, they have too many cron-esque associations. Sounds like things to be found on a to-do list on in a schedule of some sort. > Safe Python Subtask :-( > 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 ;-) cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
