Re: WebDNA 5.0 Questions
This WebDNA talk-list message is from 2003
It keeps the original formatting.
numero = 47800
interpreted = N
texte = I think I will step in to clarify the 'sandbox' feature a bit.The sandbox feature has nothing to do with the web-site licensing. Regardless of the type of licensing you use, you are not limited to the number of sandbox folders you can create. A single web-site can have multiple sandbox folders, or multiple web-sites can share a single sandbox folder. Whatever you wish to do. > If we decide to use a shared sandbox folder, the sites in that > folder clearly cannot enjoy the individual per-website sandbox > feature that we've been requesting for years. Therefore, if a bad > WebDNA programmer from one of the shared sandbox sites uploads a > destructive .tpl file which is designed to erase or delete other > files on the server, that nasty file will possibly damage or destroy > all the other files in that particular sandbox folder -- but it will > NOT have an effect on the files in any other sandbox folder. Is this > correct? Correct.> The sandbox feature can do nothing to prevent bad webdna code from > freezing or crashing the webdna software itself. Is this correct? Correct.> If so, the only solution to problematic webdna template code sems to > be for SMSI to write a better webdna engine -- so the software will > no longer crash when it encounters a template with bad webdna code in > it. Has SMSI substantially improved the webdna engine code in this > version ... so a simple webdna coding error by a user *cannot* crash > the webdna engine? I think you will agree that the current 4.5 engine is far more stable than the 4.0 release and the 5.0 engine does contain significant parser optimizations and changes that should result in even more stable operation and faster performance. BUT, I think it is unreasonable to expect any scripting language interpreter to handle any amount of foul code that is thrown at it. I can write a visual basic application that can bring down a server, and I would not blame the VB runtime component, or the OS, for 'allowing' my bad code to halt the machine. So, although we can do our best to gracefully handle bad code, WebDNA that is well designed (and tested), will always result in better overall WebDNA stability and performance.> What kind of folder hierarchy rules and limitations are we going to > have to deal with in order to make the new sandbox system work for us > *without* having to move everything around on our servers? Can we > place our individual sandbox folders anywhere we feel like putting > them, and define those sandbox folders via a new webdna preference? > If not, where must we place our sandbox folders in the hierarchy? > It is pretty straight forward. Using the new sandbox admin, you simply designate an existing folder as a WebDNA sandbox. From that point on, any template that is executed in that folder, or it subfolders, will be subject to the sandbox security limitations, which basically means that WebDNA cannot access any systems resources outside of the sandbox 'root' folder.Also, once you have designated a folder as a WebDNA sandbox, a new sandbox 'system' folder is create in the WebDNA engine folder. This sandbox system folder contains its own WebDNA Prefs file, sandbox users.db, triggers.db, emailer prefs, global folder, email folder, admin templates, etc... So a sandbox admin will be able to control their own users and WebDNA preferences. In addition, new email and trigger threads are generated for the sandbox (although the 'master' WebDNA admin can enable or disable the email and trigger threads for any sandbox, at any time). So there is no need to copy or move your site into a sandbox folder, you simply 'tag' the existing folder as a sandbox. A WebDNA sandbox is virtually like having another instance of WebDNA installed for a particular folder. > Is this sandbox feature going to work properly if we place our > individual website folders somewhere else and then place an ALIAS > of each website folder into the appropriate sandbox folder? > The sandbox code is designed to deal with 'absolute' paths, we did not intend for it to work with aliases, shortcuts, or symbolic links that point to resources outside the sandbox root. I'll let Doug handle the rest of your queries. > -----Original Message----- > From: WebDNA Talk [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf Of > Kenneth Grome > Sent: Friday, February 14, 2003 8:47 PM > To: WebDNA Talk > Subject: Re: WebDNA 5.0 Questions > > > >While Enterprise Edition is an unlimited website license, > the default for > >Developer, Partner and Commerce Editions is one website. > This allows us to > >provide a lower cost of entry into WebDNA while maintaining > flexibility. > >(References to domains in the preview document will be updated to > >websites, which is a more accurate term.) > > Hi Doug, > > The reality seems to be that we can place each of our websites into > its own folder, and then we can place all these folders into any of > the available sandbox folders for which we have a license. Is this > correct? > > Also, it seems that any sandbox folder can be used exclusively for a > single website, or it can be used by a single client for multiple > sites, or it can even be used as a 'shared sandbox' by multiple > clients (similar to the way the current version works). Is this > correct? > > If these conclusions are correct, I would like to suggest that you > use the term folder or directory -- or even sandbox -- instead > of website or domain. Because what we are actually talking about > here is the ability to define certain folders or directories as > webdna sandbox folders. I think it only confuses the issue when > you refer to them as domains or websites -- because they are > neither. > > Now on to my other questions ... > > If we decide to use a shared sandbox folder, the sites in that > folder clearly cannot enjoy the individual per-website sandbox > feature that we've been requesting for years. Therefore, if a bad > webdna programmer from one of the shared sandbox sites uploads a > destructive .tpl file which is designed to erase or delete other > files on the server, that nasty file will possibly damage or destroy > all the other files in that particular sandbox folder -- but it will > NOT have an effect on the files in any other sandbox folder. Is this > correct? > > The sandbox feature can do nothing to prevent bad webdna code from > freezing or crashing the webdna software itself. Is this correct? > If so, the only solution to problematic webdna template code sems to > be for SMSI to write a better webdna engine -- so the software will > no longer crash when it encounters a template with bad webdna code in > it. Has SMSI substantially improved the webdna engine code in this > version ... so a simple webdna coding error by a user *cannot* crash > the webdna engine? > > Is the additional sandbox price really going to be $50 each? If > not, what will the add-on price be for each additional sandbox we > wish to add to the Commerce Edition? > > Are there features OTHER THAN the protection afforded by the > unlimited private sandboxes that we will lose if we choose the > Commerce Edition over the Enterprise Edition? > > Is SMSI willing to upgrade our Commerce Edition license to an > Enterprise Edition license *at any time* simply by our paying the > difference in price between the two? In other words, let's say that > today I own a Commerce Edition with 30 additional sandbox add-ons, > for which I have paid a total of $2495. Can I upgrade to the $3995 > Enterprise Edition simply by paying the $1500 difference? Or is my > existing investment in the Commerce Edition and the 30 add-on > sandboxes not upgradable to the Enterprise Edition? > > What kind of folder hierarchy rules and limitations are we going to > have to deal with in order to make the new sandbox system work for us > *without* having to move everything around on our servers? Can we > place our individual sandbox folders anywhere we feel like putting > them, and define those sandbox folders via a new webdna preference? > If not, where must we place our sandbox folders in the hierarchy? > > Is this sandbox feature going to work properly if we place our > individual website folders somewhere else and then place an ALIAS > of each website folder into the appropriate sandbox folder? > > > Sorry for all the questions Doug, I'm just trying to understand the > changes you've made and how they relate to my future plans and > current needs. Thanks. > > > Sincerely, > Kenneth Grome > > --------------------------------------------------- > WebDNA Professional Training and Development Center > 175 J. Llorente Street +63 (32) 255-6921 > Cebu City, Cebu 6000 kengrome@webdna.net > Philippines http://www.webdna.net > --------------------------------------------------- > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list
. > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://webdna.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
I think I will step in to clarify the 'sandbox' feature a bit.The sandbox feature has nothing to do with the web-site licensing. Regardless of the type of licensing you use, you are not limited to the number of sandbox folders you can create. A single web-site can have multiple sandbox folders, or multiple web-sites can share a single sandbox folder. Whatever you wish to do. > If we decide to use a shared sandbox folder, the sites in that > folder clearly cannot enjoy the individual per-website sandbox > feature that we've been requesting for years. Therefore, if a bad > WebDNA programmer from one of the shared sandbox sites uploads a > destructive .tpl file which is designed to erase or delete other > files on the server, that nasty file will possibly damage or destroy > all the other files in that particular sandbox folder -- but it will > NOT have an effect on the files in any other sandbox folder. Is this > correct? Correct.> The sandbox feature can do nothing to prevent bad webdna code from > freezing or crashing the webdna software itself. Is this correct? Correct.> If so, the only solution to problematic webdna template code sems to > be for SMSI to write a better webdna engine -- so the software will > no longer crash when it encounters a template with bad webdna code in > it. Has SMSI substantially improved the webdna engine code in this > version ... so a simple webdna coding error by a user *cannot* crash > the webdna engine? I think you will agree that the current 4.5 engine is far more stable than the 4.0 release and the 5.0 engine does contain significant parser optimizations and changes that should result in even more stable operation and faster performance. BUT, I think it is unreasonable to expect any scripting language interpreter to handle any amount of foul code that is thrown at it. I can write a visual basic application that can bring down a server, and I would not blame the VB runtime component, or the OS, for 'allowing' my bad code to halt the machine. So, although we can do our best to gracefully handle bad code, WebDNA that is well designed (and tested), will always result in better overall WebDNA stability and performance.> What kind of folder hierarchy rules and limitations are we going to > have to deal with in order to make the new sandbox system work for us > *without* having to move everything around on our servers? Can we > place our individual sandbox folders anywhere we feel like putting > them, and define those sandbox folders via a new webdna preference? > If not, where must we place our sandbox folders in the hierarchy? > It is pretty straight forward. Using the new sandbox admin, you simply designate an existing folder as a WebDNA sandbox. From that point on, any template that is executed in that folder, or it subfolders, will be subject to the sandbox security limitations, which basically means that WebDNA cannot access any systems resources outside of the sandbox 'root' folder.Also, once you have designated a folder as a WebDNA sandbox, a new sandbox 'system' folder is create in the WebDNA engine folder. This sandbox system folder contains its own WebDNA Prefs file, sandbox users.db, triggers.db, emailer prefs, global folder, email folder, admin templates, etc... So a sandbox admin will be able to control their own users and WebDNA preferences. In addition, new email and trigger threads are generated for the sandbox (although the 'master' WebDNA admin can enable or disable the email and trigger threads for any sandbox, at any time). So there is no need to copy or move your site into a sandbox folder, you simply 'tag' the existing folder as a sandbox. A WebDNA sandbox is virtually like having another instance of WebDNA installed for a particular folder. > Is this sandbox feature going to work properly if we place our > individual website folders somewhere else and then place an ALIAS > of each website folder into the appropriate sandbox folder? > The sandbox code is designed to deal with 'absolute' paths, we did not intend for it to work with aliases, shortcuts, or symbolic links that point to resources outside the sandbox root. I'll let Doug handle the rest of your queries. > -----Original Message----- > From: WebDNA Talk [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf Of > Kenneth Grome > Sent: Friday, February 14, 2003 8:47 PM > To: WebDNA Talk > Subject: Re: WebDNA 5.0 Questions > > > >While Enterprise Edition is an unlimited website license, > the default for > >Developer, Partner and Commerce Editions is one website. > This allows us to > >provide a lower cost of entry into WebDNA while maintaining > flexibility. > >(References to domains in the preview document will be updated to > >websites, which is a more accurate term.) > > Hi Doug, > > The reality seems to be that we can place each of our websites into > its own folder, and then we can place all these folders into any of > the available sandbox folders for which we have a license. Is this > correct? > > Also, it seems that any sandbox folder can be used exclusively for a > single website, or it can be used by a single client for multiple > sites, or it can even be used as a 'shared sandbox' by multiple > clients (similar to the way the current version works). Is this > correct? > > If these conclusions are correct, I would like to suggest that you > use the term folder or directory -- or even sandbox -- instead > of website or domain. Because what we are actually talking about > here is the ability to define certain folders or directories as > webdna sandbox folders. I think it only confuses the issue when > you refer to them as domains or websites -- because they are > neither. > > Now on to my other questions ... > > If we decide to use a shared sandbox folder, the sites in that > folder clearly cannot enjoy the individual per-website sandbox > feature that we've been requesting for years. Therefore, if a bad > webdna programmer from one of the shared sandbox sites uploads a > destructive .tpl file which is designed to erase or delete other > files on the server, that nasty file will possibly damage or destroy > all the other files in that particular sandbox folder -- but it will > NOT have an effect on the files in any other sandbox folder. Is this > correct? > > The sandbox feature can do nothing to prevent bad webdna code from > freezing or crashing the webdna software itself. Is this correct? > If so, the only solution to problematic webdna template code sems to > be for SMSI to write a better webdna engine -- so the software will > no longer crash when it encounters a template with bad webdna code in > it. Has SMSI substantially improved the webdna engine code in this > version ... so a simple webdna coding error by a user *cannot* crash > the webdna engine? > > Is the additional sandbox price really going to be $50 each? If > not, what will the add-on price be for each additional sandbox we > wish to add to the Commerce Edition? > > Are there features OTHER THAN the protection afforded by the > unlimited private sandboxes that we will lose if we choose the > Commerce Edition over the Enterprise Edition? > > Is SMSI willing to upgrade our Commerce Edition license to an > Enterprise Edition license *at any time* simply by our paying the > difference in price between the two? In other words, let's say that > today I own a Commerce Edition with 30 additional sandbox add-ons, > for which I have paid a total of $2495. Can I upgrade to the $3995 > Enterprise Edition simply by paying the $1500 difference? Or is my > existing investment in the Commerce Edition and the 30 add-on > sandboxes not upgradable to the Enterprise Edition? > > What kind of folder hierarchy rules and limitations are we going to > have to deal with in order to make the new sandbox system work for us > *without* having to move everything around on our servers? Can we > place our individual sandbox folders anywhere we feel like putting > them, and define those sandbox folders via a new webdna preference? > If not, where must we place our sandbox folders in the hierarchy? > > Is this sandbox feature going to work properly if we place our > individual website folders somewhere else and then place an ALIAS > of each website folder into the appropriate sandbox folder? > > > Sorry for all the questions Doug, I'm just trying to understand the > changes you've made and how they relate to my future plans and > current needs. Thanks. > > > Sincerely, > Kenneth Grome > > --------------------------------------------------- > WebDNA Professional Training and Development Center > 175 J. Llorente Street +63 (32) 255-6921 > Cebu City, Cebu 6000 kengrome@webdna.net > Philippines http://www.webdna.net > --------------------------------------------------- > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://webdna.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Scott Anderson
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
New Lawsuit Alleges Unitedhealth/Pacificare Deceived (2006)
New public beta available (1997)
Emailer (WebCat2) (1997)
Emailer choke (1997)
Updating database (1998)
WebCatalog for Postcards ? (1997)
WCS Newbie question (1997)
[countwords] (2002)
Multiple Currencies (2002)
system crashes, event log (1997)
WC2b15 File Corruption (1997)
redirect with frames (1997)
Calculating multiple shipping... (1997)
Safari browser and WebDNA set-cookies (2003)
Problems setting MIME Headers (1998)
can anyone confirm this behavior? (2003)
[writefile] (1997)
Security Issues and WebCommerce Solution (1997)
WebCatalog and WebTen (1997)
FEA REQ: One .hdr, multiple .db's (2003)