Phaas - anyone interested in setting up Pharo as a Service?

> <I am merging my responses to Bernat and Stephane>
>
> I agree that there are probably too few webdevs to make this viable -
> yet :-). However, we may be able to build on other people's work.
>
> For example, I have been quite impressed by OpenShift. I wondered if
> someone could create a Pharo (or gemstone) cartridge. That would then
> give us access to the rest if their system. It might then allow anyone
> to set up their own system, just by using that cartridge.
>
> Obviously, someone would need to keep the cartridge up to date etc,
> and maybe a first step would be to adapt the work on Harbour to make
> image uploading easier.
>
> At this point, as I am sure you can tell, I am way beyond my
> expertise, so I am just guessing. However, it does seem as though
> people - such as redhat - are doing a lot if the work for us, and it
> could be smart to build on their structures.
>
> Has anyone tried creating a cartridge? Or would someone like to try? I
> am happy to sponsor part of this, if that helps.
>
> Cheers
> Andy
>

> 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?

>> he, sorry for insist, but cloudfoundry already does that... and is opensource too :)
>> at ESUG I seen James present it to deploy pharo images... so is viable :)
>>
>> cheers,
>> Esteban
>>
>
> I agree. And, I was really quite optimistic about cloud foundry when
> it first came out. I particularly like the way you can have a local
> micro cloud, and then transition to the hosted cloud. My only
> disappointment was that VMware are not - seemingly - going to offer
> gemstone as an option on cloudfoundry.com.
> Building on what Janko said, I think it is really important to join
> the cloud 'wave'.
>
> The question is how might we - collectively - make this happen? I am
> perfectly happy to go with cloud foundry, or open shift, or any other
> option if more knowledgeable people can show that X is the way to go.
> My only requirement is that I don't want to deal with anyone lower
> than pharo. All OS patches need to be done automagically by the
> hosting provider. I think cloudfoundry.com and open shift do that, but
> my understanding of cloudfoundry.org is that this is a 'roll it
> yourself' solution. Obviously, that would require someone to step up
> and do that for us.
> My preference would be for us to create a suitably configured module
> for one of e platforms, and we can then start getting experience with
> it.  Stephane, is this something that the consortium might take a lead
> on? My company is happy to pay some of the costs, if this will help.
>
> Cheer
> Andy
>

> <<<
> I would prefer to upload a MetacelloConfiguration (or something similar)
> instead of an image.
>
> I like to think about the image as a temporary runtime. Not something
> where I store code or someting I deploy. I would love to have something
> like:
>
>       $ pharo -v 1.4-summer myProject.ston
>
> where myProject.ston would contain all the necessary information to load
> my project (dependencies, repositories, etc). This command would create
> an image with my project on the fly from a stock Pharo 1.4-summer and
> launch it. It would recreate the image everytime I want to work on my
> project (or when it is deployed).
>
> The problem right now is the loading time for dependencies (try to load
> seaside in a pristine image, you'll get the point). All the other bricks
> are there.>>>
>
> Sounds like a very good idea. Does anything like that exist already?
> Also, it raises the question of what should be in the base image.

>>>
>>
>> I'm not aware of any.
>> Tanker[1] + Metacello are maybe an answer for the loading time issue.
>>
>>
>> [1]: http://marianopeck.wordpress.com/2012/09/28/new-tanker-current-status/
>
> But it requires some work to make it production ready.
> I do not think that you need ston. You plain smalltalk code is good enough to trigger the correct metacello file.
>
> metacello is key for the projects dependency management and complex projects.
> Once we will have the continuous validation of pckage ready + binary loader we will get ready for a new phase
> in Pharo.
>
> Stef

> On Jan 26, 2013, at 7:30 AM, Francois Stephany <[hidden email]> wrote:
>
>> On 26/01/13 02:02, Andy Burnett wrote:
>>> 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.
>>
>> I would prefer to upload a MetacelloConfiguration (or something similar) instead of an image.
>
> I built CloudFoundry so that you uploaded a .st file (in my ESUG example it was 'aida.st') that was used to build the image. The server executed the .st file and saved the resulting image (it could load .mcz files directly or execute a Metacello script). Whenever your application was needed, a copy of the saved image was used.