I can send you a Google Plus invite if you want one as I got heaps of the things still.
BTW, am I wrong in assuming that you are an existing web hosting service providing PHP and getting into Python? Based on early emails that is what I figured and why I took that stance, but your last email after I posted on Google Plus made me think perhaps instead that you were starting from scratch given you are looking at merits of VMs versus other options. If you are starting this from scratch with no legacy systems to try and work with, would be extremely interested to know as I like keeping across all the different options coming out. You can see where have been tracking some on: http://blog.dscpl.com.au/2011/01/awesome-year-for-python-web-hosting.html I know of some others as well, but can't say anything about them as they haven't said publicly what they are up to. Graham On 27 August 2011 18:31, Chen Zheng <[email protected]> wrote: > I don't have google+ account yet, but I'll keep an eye on that subject. > > Thank you so much Graham, I wish I can buy you a beer, lol > > > On 27 August 2011 15:54, Graham Dumpleton <[email protected]> wrote: >> FWIW, you might follow: >> >> https://plus.google.com/114657481176404420131/posts/fk7Do3gULKe >> >> I have put my thoughts out there and asked the question of others in >> Python web world that follow me what they reckon. >> >> As to your two extremes. The VM approach is what CloudFoundry/Stackato >> are doing. Google App Engine is the modified Python and execution >> environment. There are other approaches used and I mention some >> companies in that post. Another which has a leaning more towards >> traditional hosting services is dotCloud who rely on uWSGI. >> >> Graham >> >> On 27 August 2011 17:28, Chen Zheng <[email protected]> wrote: >>> On 27 August 2011 14:32, Graham Dumpleton <[email protected]> >>> wrote: >>>> On 27 August 2011 15:57, Chen Zheng <[email protected]> wrote: >>>>> Wow, quite a lot to digest, I'll reconsider the situation, thank you >>>>> very much for the advices, detailed and patient explanations. >>> >>>>> Concurrent request is not limited, you can have as many worker >>>>> processes as you can to handle the requests, they are controlled and >>>>> started automatically by app server like apache as requests coming in. >>>>> >>>>> What's limited here is the function of spawning new thread or process >>>>> in your application handler code. >>>> >>>> And as I said, not being able to spawn a background thread will stop >>>> various code from not working. >>>> >>>> More so now that you are also saying that it will not be possible to >>>> spawn a new process. >>>> >>>> Was the intention only to try and block the fork call, or were you >>>> intending to also block even stuff like os.system() and os.popen() >>>> etc? >>>> >>>> Are you trying to do this at kernel level or intending to try and run >>>> Python in a restricted mode using a customised Python? >>> >>> >>> The latter. Currently it's just in experimental phrase, we're trying >>> to leverage as much we can. Let users run their code unmodified is >>> perfect, but it seems impossible unless an isolated vm instance is >>> provided. >>> >>> Hope we'll find the balance, minimize the migration cost of existing apps. >>> >>> Jaime >>> >>>> Google App Engine does use a customised version of Python and other >>>> methods to implement similar sorts of restrictions. Google gets away >>>> with forcing such restrictions and requiring applications to be >>>> written to suit their platform mostly because of who they are, but is >>>> your intention to be of that sort of platform, or are you trying to >>>> provide a system where anyone can run any application they want >>>> without having to modify it. If the latter, I think you will find this >>>> sort of restrictions to be a big turn off to users. There are times >>>> where people will want to use background threads or execute system >>>> applications to do stuff. Even Python itself when querying stuff via >>>> the 'platform' module will run external applications like 'uname' to >>>> get information. Stuff like this will break if you are going to block >>>> creation of all new processes. >>>> >>>> Graham >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "modwsgi" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> For more options, visit this group at >>>> http://groups.google.com/group/modwsgi?hl=en. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "modwsgi" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/modwsgi?hl=en. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/modwsgi?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
