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 [email protected] > 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: [email protected] > _______________________________________________ > Devl mailing list > [email protected] > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
