On 14 Aug 2014, at 22:40, François Stephany <tulipe.mouta...@gmail.com> wrote:
> Ah ! I was also thinking about a cookie to keep user identity, I hate to > re-login because of an expired session. I was looking for a good name, > "login-token" sounds good :) It works pretty well in practice (this is a mobile app mostly), even if the Seaside session expires, your login survives and you are moved to some sensible state (but that has to be programmed explicitly). > Why do you keep it 14 days only ? Is there a reason ? I planned to make it > valid much longer than that... Allowing a login to remain valid forever feels like a bad idea, but I guess the number is not necessarily fixed and should not be the same for everyone. Now, after 14 days not touching the web app from an open browser/tab you will have to do a new login, that is not that bad IMO. I would even say the UX says (implicitly) 'we closed your session for security reasons'. > On Thu, Aug 14, 2014 at 10:27 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > On 14 Aug 2014, at 15:21, François Stephany <tulipe.mouta...@gmail.com> wrote: > > > Good idea, I add monit as one of the next step. > > > > Load balancing is not supported at all. But we could change the nginx > > config file to load balance between two images. And maybe make something > > for Seaside and its state (sticky sessions?). I haven't done enough of this > > to actually take an informed decision. > > Here is some information on how I did it recently using nginx and Seaside: > > http://forum.world.st/Nginx-Load-Balancing-Experiences-td4750823.html > > The stickiness is by client IP. > > It is also possible to do route based stickiness in Seaside and using Zinc > (see ZnServer>>#route:), but I know only how to do that with Apache 2 (it is > a paying option for nginx sadly). > > Of course, in most cases you will have to do some session state sharing > between instances. I used memcached for that. > > > I'll update the README to be more clear about what is done behind the > > scene. Showing the tree of directories created by HelloPharo will be worth > > a thousand words (especially if you've used capistrano before). > > > > > > On Thu, Aug 14, 2014 at 3:13 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > > On 14 Aug 2014, at 13:08, François Stephany <tulipe.mouta...@gmail.com> > > wrote: > > > > > Oh, I forgot to mention Sven. He wrote the original > > > http://stfx.eu/pharo-server/ > > > We basically stole all his Bash-fu to build the main script: > > > > > > https://github.com/fstephany/hello-pharo/blob/master/app > > > > > > Thanks a lot Sven! > > > > You're welcome, François. BTW, I am still using that script for all my > > deploys. > > > > I didn't immediately see it, but does your solution include something for > > process monitoring and automatic restarts (like monit) and/or some basic > > load balancing ? In my experience the combination of these two makes for a > > more robust solution. Maybe that is the next step ;-) > > > > Sven > > > > > On Thu, Aug 14, 2014 at 1:02 PM, François Stephany > > > <tulipe.mouta...@gmail.com> wrote: > > > Hello, > > > > > > At Ta Mère, we are used to deploy Ruby/Rails application with Heroku or > > > on VPS with Capistrano. Almost everybody uses the same tools and > > > techniques in the Rails community so deployment is quite easy once you > > > grasp the process. > > > > > > The same process was quite frustrating with Pharo. To solve that, we've > > > built HelloPharo. It is a tool to deploy small apps to a Linux VPS/VM. > > > > > > It is heavily inspired by Capistrano, it prones convention over > > > configuration and it wants to be full stack (e.g., serve the assets, > > > restart the processes). It is built with Ansible. > > > > > > We haven't released a fixed version yet but the tool starts to be in a > > > good-enough shape to be shown. We want to grab some feedback and fix the > > > most obvious limitations (see the README for more) before releasing > > > version 0.1.0. > > > > > > If you or your company uses a well defined process to deploy pharo > > > webapps, we are all ears. We think that having a canonical way to deploy > > > simple apps is a must if we want to see wider Pharo adoption for small > > > web companies. This process *must* be Unix friendly if we want to attract > > > Python or Ruby people. Most of them are Devops anyway, the command line > > > is their friend, NOT something they want to avoid. > > > > > > Pull requests (for code or instructions in the README) are more than > > > welcome. The code and the documentation are MIT licensed. > > > > > > https://github.com/fstephany/hello-pharo/ > > > > > > Cheers, > > > Francois > > > > > > > > > > > _______________________________________________ > > Pharo-business mailing list > > pharo-busin...@lists.pharo.org > > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org > >
