Hi Andy, On 26 Jan 2013, at 02:02, Andy Burnett <[email protected]> wrote:
> We would love to develop more of our ideas in Pharo, but we are completely > allergic to doing sys admin. We don't want to deal with anything below the > Pharo application level. What I would ideally like to see if something like > Heroku, or similar, but for Pharo. However, just wishing won't make it > happen, so I am wondering if there is anyone out there who is thinking about > this, and whether there are enough of us to constitute are market. > > Our requirements are pretty simple. We need a way of uploading an image, and > some standard for of persistence. At this point, we would be perfectly happy > to make compromises by agreeing that it had to be e.g. Mongo or whatever > (although ideally it would be gemstone). We just want to make some progress > on this. > > Personally, I think lots of bits are coming together. We now have various > persistence options, websockets (both in Zinc and Aida-web), OAuth ( in both > places again), and lots of other exciting elements. We just want a really > simple way to take advantage of them. > > Does anyone else feel this need? (I am reacting to the whole thread - all this is IMHO) Yes, I think this would be nice to have. The way I see it, the necessary technology is all there. Even better: it was all there years ago (Seaside, AIDA/Web, Glorp, seasidehosting.st, and so much more), and in recent years we made important progress (Pharo taking off as the most forward thinking open source Smalltalk, Cog VM doubling performance, many, many large and small projects adding more and more technologies, interesting fundamental changes in Pharo which are and will pay off big time in the future). If you have been following this list, you know that deploying all kinds of Pharo Smalltalk based applications in the cloud is daily business. But of course, it requires some expertise, some of which is outside Smalltalk itself. A number of people, including myself, could help you with the definition of a production architecture and a way to deploy and operate your application. In the realm of more managed solutions, OpenShift has been done, CloudFoundry has been done. It is not that hard, but it is still pretty technical. So your idea comes down to an easier to use platform for deploying. I would consider uploading images a bit old school. Just specify your app as a Metacello configuration, and let it build by a continuous integration farm working in stages to deal with the longer build times of some packages, but with unit tests. To run, a single expression passed along the command line is enough. Of course, a nice web based management interface is necessary. The challenge is this: to make the platform easier to use, the process and solution space have to be simplified, and choices have to be made. In a community like ours with so many intelligent but also strong headed people, it can be hard to find consensus. In general, that is not a problem: more choices, alternatives, competing ideas, may the best win, are OK - fragmentation is the price to pay. But many complicated choices and alternatives are in conflict with an easy to use platform. For example, Google Apps has a limited set of very specific services, you can't install arbitrary code (so also no Smalltalk). This makes for one clear way to use it. Hence, it might be easier to use. Now, the perspective of doing this commercially is challenging. There currently are probably only a limited number of people really willing to pay for this (and it would depend very much on the choices being made). But that might be a chicken and egg problem: before Ruby on Rails, Ruby was certainly a niche language, in the beginning of RoR, it probably made little sense to do Heroku. But even today, not everybody deploys to Heroku, because they need more control (over resource or money). Maybe it just takes somebody crazy enough to try. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
