Hi Rafael, I looked at your blohg project, and I'm wondering how do you compare yourself to projects such as hyde (http://hyde.github.com/). Hyde works pretty much the same: Jinja2 + YAML + text files (+ VCS), and has in my opinion the great advantage of generating static pages. Not every one has a web app server ready to fire, but everyone can have a bitbucket account to host his static pages. In your case, I'm wondering what does the dynamic side of Flask brings to your project, as you're generating pseudo-static pages anyway ... Regards, Benoit
On Thu, Nov 17, 2011 at 04:49:26PM +0100, Ben wrote: > Hi Rafael, > > I looked at your blohg project, and I'm wondering how do you compare > yourself to projects such as hyde (http://hyde.github.com/). Hyde > works pretty much the same: Jinja2 + YAML + text files (+ VCS), and > has in my opinion the great advantage of generating static pages. Not > every one has a web app server ready to fire, but everyone can have a > bitbucket account to host his static pages. > > In your case, I'm wondering what does the dynamic side of Flask brings > to your project, as you're generating pseudo-static pages anyway ... Not to answer for Rafael, but: Static-generator blogging packages and dynamic-serving blogging packages both have their advantages. If I wasn't already running a server I'd consider the former, but as long as I am the advantages of dynamic serving help me in a lot of ways: I use the dynamic nature of the page generation to return different content for different operating systems/browsers/languages, return different last-modified-times (I don't think BB or github allow you to set those, but I could be wrong), to do a ton of redirects and rewrites from old URLs to new ones (this is my 3rd blogging platform with the same 10 year old content). Static has some definite advantages w/r/t ease of hosting and performance under load, but a dynamic blogging packag can always yield static files with a final 'wget --mirror' command run against the debug server if that's the only hosting option available to you and adding a caching http reverse proxy (or mod_cache) yields the best of both world w/r/t server performance. One other advantage might be the ability to combine tags at the URL level. Someone can easily get a list of every every post I have tagged with 3 arbitrary tags from my set of 14, which would be a real combinatoric explosion on a static site, but with a dynamic site it's just: http://ry4an.org/unblog/tag/ideas-built/perl/funny/ Definitely a case where there's no right or wrong, but I like the flexibility of controlling my servings, and always have the option to use a wget mirror if I want static. -- Ry4an Brase - http://ry4an.org/
On Thu, Nov 17, 2011 at 2:33 PM, Ry4an Brase <ry4an-blohg@ry4an.org> wrote: > On Thu, Nov 17, 2011 at 04:49:26PM +0100, Ben wrote: >> Hi Rafael, >> >> I looked at your blohg project, and I'm wondering how do you compare >> yourself to projects such as hyde (http://hyde.github.com/). Hyde >> works pretty much the same: Jinja2 + YAML + text files (+ VCS), and >> has in my opinion the great advantage of generating static pages. Not >> every one has a web app server ready to fire, but everyone can have a >> bitbucket account to host his static pages. >> >> In your case, I'm wondering what does the dynamic side of Flask brings >> to your project, as you're generating pseudo-static pages anyway ... > > Not to answer for Rafael, but: > > Static-generator blogging packages and dynamic-serving blogging packages > both have their advantages. If I wasn't already running a server I'd > consider the former, but as long as I am the advantages of dynamic > serving help me in a lot of ways: > > I use the dynamic nature of the page generation to return different > content for different operating systems/browsers/languages, return > different last-modified-times (I don't think BB or github allow you to > set those, but I could be wrong), to do a ton of redirects and rewrites > from old URLs to new ones (this is my 3rd blogging platform with the > same 10 year old content). > > Static has some definite advantages w/r/t ease of hosting and > performance under load, but a dynamic blogging packag can always yield > static files with a final 'wget --mirror' command run against the debug > server if that's the only hosting option available to you and adding > a caching http reverse proxy (or mod_cache) yields the best of both > world w/r/t server performance. > > One other advantage might be the ability to combine tags at the URL > level. Someone can easily get a list of every every post I have tagged > with 3 arbitrary tags from my set of 14, which would be a real > combinatoric explosion on a static site, but with a dynamic site it's > just: http://ry4an.org/unblog/tag/ideas-built/perl/funny/ > > Definitely a case where there's no right or wrong, but I like the > flexibility of controlling my servings, and always have the option to > use a wget mirror if I want static. > Ry4an said almost everything... I'll just add a couple of words... We don't want to make you use blohg. blohg just have some cool features that were implemented as needed and when suggested, and people using it enjoy them. You're free to choose what suits you better, and that's the fun ;o) Best Regards! -- Rafael Goncalves Martins http://rafaelmartins.eng.br/
On 18 nov. 2011, at 21:39, Rafael Martins <rafael@rafaelmartins.eng.br> wrote: > On Thu, Nov 17, 2011 at 2:33 PM, Ry4an Brase <ry4an-blohg@ry4an.org> wrote: >> On Thu, Nov 17, 2011 at 04:49:26PM +0100, Ben wrote: >>> Hi Rafael, >>> >>> I looked at your blohg project, and I'm wondering how do you compare >>> yourself to projects such as hyde (http://hyde.github.com/). Hyde >>> works pretty much the same: Jinja2 + YAML + text files (+ VCS), and >>> has in my opinion the great advantage of generating static pages. Not >>> every one has a web app server ready to fire, but everyone can have a >>> bitbucket account to host his static pages. >>> >>> In your case, I'm wondering what does the dynamic side of Flask brings >>> to your project, as you're generating pseudo-static pages anyway ... >> >> Not to answer for Rafael, but: >> >> Static-generator blogging packages and dynamic-serving blogging packages >> both have their advantages. If I wasn't already running a server I'd >> consider the former, but as long as I am the advantages of dynamic >> serving help me in a lot of ways: >> >> I use the dynamic nature of the page generation to return different >> content for different operating systems/browsers/languages, return >> different last-modified-times (I don't think BB or github allow you to >> set those, but I could be wrong), to do a ton of redirects and rewrites >> from old URLs to new ones (this is my 3rd blogging platform with the >> same 10 year old content). >> >> Static has some definite advantages w/r/t ease of hosting and >> performance under load, but a dynamic blogging packag can always yield >> static files with a final 'wget --mirror' command run against the debug >> server if that's the only hosting option available to you and adding >> a caching http reverse proxy (or mod_cache) yields the best of both >> world w/r/t server performance. >> >> One other advantage might be the ability to combine tags at the URL >> level. Someone can easily get a list of every every post I have tagged >> with 3 arbitrary tags from my set of 14, which would be a real >> combinatoric explosion on a static site, but with a dynamic site it's >> just: http://ry4an.org/unblog/tag/ideas-built/perl/funny/ >> >> Definitely a case where there's no right or wrong, but I like the >> flexibility of controlling my servings, and always have the option to >> use a wget mirror if I want static. >> > > Ry4an said almost everything... I'll just add a couple of words... > > We don't want to make you use blohg. blohg just have some cool > features that were implemented as needed and when suggested, and > people using it enjoy them. You're free to choose what suits you > better, and that's the fun ;o) > Sure, thanks for all those answers, that's actually the reason I was asking, trying to find the best tool for my need ... Unfortunately, it looks like 'wget --mirror' + 'blohg' would also fit my bill ;-). One more on the list ... That's not making my choice easier ! You'll probably hear from me again ! Best Regards, Ben.
On Sat, Nov 19, 2011 at 5:05 PM, Ben <benoit.allard@gmx.de> wrote: > On 18 nov. 2011, at 21:39, Rafael Martins <rafael@rafaelmartins.eng.br> wrote: > >> On Thu, Nov 17, 2011 at 2:33 PM, Ry4an Brase <ry4an-blohg@ry4an.org> wrote: >>> On Thu, Nov 17, 2011 at 04:49:26PM +0100, Ben wrote: >>>> Hi Rafael, >>>> >>>> I looked at your blohg project, and I'm wondering how do you compare >>>> yourself to projects such as hyde (http://hyde.github.com/). Hyde >>>> works pretty much the same: Jinja2 + YAML + text files (+ VCS), and >>>> has in my opinion the great advantage of generating static pages. Not >>>> every one has a web app server ready to fire, but everyone can have a >>>> bitbucket account to host his static pages. >>>> >>>> In your case, I'm wondering what does the dynamic side of Flask brings >>>> to your project, as you're generating pseudo-static pages anyway ... >>> >>> Not to answer for Rafael, but: >>> >>> Static-generator blogging packages and dynamic-serving blogging packages >>> both have their advantages. If I wasn't already running a server I'd >>> consider the former, but as long as I am the advantages of dynamic >>> serving help me in a lot of ways: >>> >>> I use the dynamic nature of the page generation to return different >>> content for different operating systems/browsers/languages, return >>> different last-modified-times (I don't think BB or github allow you to >>> set those, but I could be wrong), to do a ton of redirects and rewrites >>> from old URLs to new ones (this is my 3rd blogging platform with the >>> same 10 year old content). >>> >>> Static has some definite advantages w/r/t ease of hosting and >>> performance under load, but a dynamic blogging packag can always yield >>> static files with a final 'wget --mirror' command run against the debug >>> server if that's the only hosting option available to you and adding >>> a caching http reverse proxy (or mod_cache) yields the best of both >>> world w/r/t server performance. >>> >>> One other advantage might be the ability to combine tags at the URL >>> level. Someone can easily get a list of every every post I have tagged >>> with 3 arbitrary tags from my set of 14, which would be a real >>> combinatoric explosion on a static site, but with a dynamic site it's >>> just: http://ry4an.org/unblog/tag/ideas-built/perl/funny/ >>> >>> Definitely a case where there's no right or wrong, but I like the >>> flexibility of controlling my servings, and always have the option to >>> use a wget mirror if I want static. >>> >> >> Ry4an said almost everything... I'll just add a couple of words... >> >> We don't want to make you use blohg. blohg just have some cool >> features that were implemented as needed and when suggested, and >> people using it enjoy them. You're free to choose what suits you >> better, and that's the fun ;o) >> > > Sure, thanks for all those answers, that's actually the reason I was asking, trying to find the best tool for my need ... Unfortunately, it looks like 'wget --mirror' + 'blohg' would also fit my bill ;-). One more on the list ... That's not making my choice easier ! > > You'll probably hear from me again ! > You're welcome, Ben. Some time ago I heard some guy talking about create a flask-script [1] (our command-line tool is powered by it) command to build a static version of blohg using the froozen-flask extension [2], but looks like this didn't moved forward. Maybe you're interested in play with this and send us a patch, or know someone who are :) [1] http://packages.python.org/Flask-Script/ [2] http://packages.python.org/Frozen-Flask/ Best regards, -- Rafael Goncalves Martins http://rafaelmartins.eng.br/
On Sat, Nov 19, 2011 at 21:04, Rafael Martins <rafael@rafaelmartins.eng.br> wrote: > > Some time ago I heard some guy talking about create a flask-script [1] > (our command-line tool is powered by it) command to build a static > version of blohg using the froozen-flask extension [2], but looks like > this didn't moved forward. > > Maybe you're interested in play with this and send us a patch, or know > someone who are :) > > [1] http://packages.python.org/Flask-Script/ > [2] http://packages.python.org/Frozen-Flask/ > Me, reporting on that one ... The first trouble is that most of the pages served by blohg are served with a directory-like URL (ending on /). While I do believe that this has been designed on purpose, during frozen export, this force us to generate directories and ... index.html files. Those files are suitable when we are talking about html, unfortunately, when serving plain text (source) or xml (atom feed), this does not really match. The action to be taken is to my understanding pretty straight forward: for the frozen export to work, we have to serve (at least the non-html stuff) with file extensions. I could add new rules for those two views at least, then the generated urls will contains extensions, but the downside of this is that I'm adding extensions for everyone ... Is there a way to tweak the "routes" on a configuration basis ? Kind of: If I am frozing generate the route with '.html', else with '/'. Maybe I can rewrite the url_map just before freezing the app ... I'll have a look at this option ... Regards, Ben
On Sat, Nov 19, 2011 at 21:04, Rafael Martins <rafael@rafaelmartins.eng.br> wrote: > Some time ago I heard some guy talking about create a flask-script [1] > (our command-line tool is powered by it) command to build a static > version of blohg using the froozen-flask extension [2], but looks like > this didn't moved forward. > > Maybe you're interested in play with this and send us a patch, or know > someone who are :) Here we go: https://bitbucket.org/benallard/blohg For the good points: - It works ! For the less good points - I had to return something for /source/, Frozen-Flask don't like 404 For the bad points - I don't really know where it's gonna be generated. Frozen-Flask uses `app.root_path + something`. Chance are big that this points to a lib subdirectory at our place. If someone knows the maintainer of Frozen-Flask, it could be an idea to ask him to make this path more parametrizable. pull or comment ! Regards, Ben