I forgot the main advantage of the solution I'm proposing: AWS will get us a free wildcard certificate for everything we host on their infrastructure (we're currently paying for it and it will come due for renewal in April) without us having to fill in any paperwork (it's been a problem in the past).
Florent On Sun, 2016-10-30 at 18:33 +0100, Florent Daigniere wrote: > My favourite solution would be based on AWS: > > S3 for storage, cloudfront as a CDN in front > > A Lambda function to trigger rebuilds when the bucket is updated (or > an > api-endpoint we'd get github to trigger on commit) > > > As for the static-page generator, I am allergic to ruby's ecosystem. > Not > because it doesn't work but because maintaining the dependencies over- > time is just impossible. > > I'd suggest > https://gohugo.io/ (a static page generator built on golang - static) > https://github.com/ryansb/hugo-lambda > or Pelican (a python-based one that's maintained/available in pip) > > Florent > > On Sun, 2016-10-30 at 16:51 +0000, Ian Clarke wrote: > > On Sun, Oct 30, 2016 11:37 AM, Dan Roberts ademan...@gmail.com > > wrote:Shall I proceed for the moment assuming that we're using > > github > > pages? > > > > If we abandon github pages, that frees me to identify and select a > > more > > > > i18n friendly site generator, so I haven't put much more work into > > the > > > > Jekyll version. At present the Jekyll version's English translation > > is > > > > effectively complete, however I do think some content curation will > > be > > > > necessary to better fit the new format. > > > > > > I think this requires discussion, let's consider the options. I > > think > > we can > > all agree that we're looking for a solution that is a) cheap or free > > and b) > > hosted by a 3rd party, so we don't have to worry about > > security/scalability/etc. > > Github pages is definitely the easiest, and it's free, and you're > > already down > > the road with that through Jekyll, but it sounds like the experience > > for > > non-English-speaking users will be suboptimal, perhaps relying on a > > JavaScript > > powered redirect, which itself may rely on a 3rd-party service since > > JavaScript > > apparently can't tell what the user's preferred language is (even > > though it is > > part of every HTTP request). It is also worrying that Github Pages > > doesn't > > support HTTPS for a custom domain - might this result in broken > > inbound links? > > Google App Engine gives us a lot more flexibility, but it would also > > be a > > reasonable amount of additional coding, and probably wouldn't be as > > amenable to > > collaborative editing as Github Pages. GAE isn't free, but the cost > > is likely > > negligible given how much traffic we get. > > A possible compromise would be a simple redirecting service on > > Google > > App Engine > > which only served to identify the user's preferred language, and > > then > > redirect > > to the appropriate page on Github Pages (or set a cookie that is > > visible from > > JavaScript). Again, more work, and could be messy (we'd probably > > need > > to use a > > different subdomain for the Github Pages site). > > > > Thoughts? What other options are there? > > > > Ian. > > Ian Clarke > > Founder, The Freenet Project > > Email: i...@freenetproject.org > > _______________________________________________ > > Devl mailing list > > Devl@freenetproject.org > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
