3 ms·

Wow, this is a really amazing concept, even if it's still a little rough around the edges. I think it's going to take a while for people to see the value here b

by ed 19y ago

Wow, this is a really amazing concept, even if it's still a little rough around the edges. I think it's going to take a while for people to see the value here but honestly this rocks. <braindump> You're gonna need to support more libraries. I'm making a util to turn a page of thumbnails into a page of inline full-sized images and am going to need re to do it. At the very least create a whitelist of allowed imports; I'd really like to be able to use urllib2, re, some HMTL/XML parsers, etc... The best use of a service like this appears to me to be writing little web clients to interact with existing web services, kinda like you're writing shell scripts for the web. And branding aside, I think you're going to need a new definition for "utility." It's a little too ambiguous. I think there's a lot of potential value here but am also wondering about possible revenue models. Maybe restrict system resources for free accounts or offer additional libraries for premium members? Seems like this would be a sub-optimal site to monetize through advertising. </braindump>

tocomment 19y ago
Thanks ed. I'm really glad you like it. There are allowed utilities currently: "calendar, datetime, difflib, math, random ,re, string, time, and urllib are already imported." I did strip out things that connect to other websites though. I'm not sure how I could allow outgoing connections, and still prevent a malicious user from sending spam, or other bad things? But I'll add that down the road perhaps. I'm aiming to change the security system so that the entire Python interpreter is open to users within a few weeks. (I'm still not sure about outgoing connections though). Any ideas for the branding? Why is utility too ambiguous? For revenue, so far I'm thinking having premium accounts someday with cool features like download desktop app version of any utility, or standalone CGI script.
- ed 19y ago
  > "I did strip out things that connect to other websites though. I'm not sure how I could allow outgoing connections, and still prevent a malicious user from sending spam, or other bad things? But I'll add that down the road perhaps." That's a shame. I was wondering why openurl didn't work. Why import the module if you don't allow outgoing connections? You will have to address the spam issue eventually but really that's almost a problem of success; focus on it when you need to. Until then, disallowing outgoing connections is overly restrictive and cripples what could potentially be a really cool service. I also noticed that try...except blocks are blocked as well. Why is that?
  - tocomment 19y ago
    Good points. Maybe I'll put outgoing connections back in then. Until there are 100's of new utilities every day, I could probably keep an eye on things. The security code I found doesn't allow try ..except, I'm not sure why. In any case, what I'm working on right now is a way to remove most or all of the restrictions. I'll let you know when that's up and running.

by ed 19y ago

tocomment 19y ago

Thanks ed. I'm really glad you like it. There are allowed utilities currently: "calendar, datetime, difflib, math, random ,re, string, time, and urllib are already imported." I did strip out things that connect to other websites though. I'm not sure how I could allow outgoing connections, and still prevent a malicious user from sending spam, or other bad things? But I'll add that down the road perhaps. I'm aiming to change the security system so that the entire Python interpreter is open to users within a few weeks. (I'm still not sure about outgoing connections though). Any ideas for the branding? Why is utility too ambiguous? For revenue, so far I'm thinking having premium accounts someday with cool features like download desktop app version of any utility, or standalone CGI script.

ed 19y ago
> "I did strip out things that connect to other websites though. I'm not sure how I could allow outgoing connections, and still prevent a malicious user from sending spam, or other bad things? But I'll add that down the road perhaps." That's a shame. I was wondering why openurl didn't work. Why import the module if you don't allow outgoing connections? You will have to address the spam issue eventually but really that's almost a problem of success; focus on it when you need to. Until then, disallowing outgoing connections is overly restrictive and cripples what could potentially be a really cool service. I also noticed that try...except blocks are blocked as well. Why is that?
- tocomment 19y ago
  Good points. Maybe I'll put outgoing connections back in then. Until there are 100's of new utilities every day, I could probably keep an eye on things. The security code I found doesn't allow try ..except, I'm not sure why. In any case, what I'm working on right now is a way to remove most or all of the restrictions. I'll let you know when that's up and running.