I’ve decided the nickname.
FlatPress 0.1010 will be Sotto Voce.
:)
I’ve decided the nickname.
FlatPress 0.1010 will be Sotto Voce.
:)
Very few changes in SVN. So I guess I’ll give it one week and then release. How about that? :)
You can get the new release; JavaScript powered by jQuery (contributed by PieroVDFN), more safe indexing backend, a lot of bugfixes, yadayada.
This version is almost final, so if you find any bug, just report it on the forums!
Bye!
Big news for the FlatPress site! We’ve moved our site to the modern, professional and award winning Linux Hosting company A2 Hosting.
Their 24/7 support crew is very friendly and knowledgeable. And best of all, they offer FlatPress hosting! If you need a new place for your FlatPress blog, I suggest you consider their reliable FlatPress offering. They even offer free site transfers for users who are currently using a host with the cPanel control panel.
A2 FlatPress Hosting includes:
Get these bells and whistles and much more for about $5/month!
Still not convinced? Check out the top 10 reasons to choose A2 Hosting. You’ll be impressed!
In the meantime, I hope you’ll enjoy our new place. I’ve already upgraded the forums to the latest version of Vanilla (which didn’t work on my old servers).
Please, test the development version (SVN) of FlatPress, I’m planning to release a new version as soon as all the bugs are ironed out.
One of my aim for FlatPress was making it *fast*; now, we can all probably agree that a flat file system is not probably the best way to guarantee speed.
In fact, with the word ‘fast’ I don’t mean *absolutely* fast, but *perceived* as fast; this in fact implies answering to a user request as soon as possible, which is generally accomplished by doing the least necessary to show some user interface, and then showing the progress in some way.
e.g. When you download a file, a progress dialog with a bar will show up.
In FlatPress, being ‘fast’ means starting spitting out the part of the page which needs the least effort, and advance progressively.
While this is best practive in common interaction design, it’s not so provably ‘the best’ approach when we speak about web apps and web sites, since spitting out pieces might imply the webserver and the user client will have to negotiate the size of the chunks multiple times, which in turn would make the download bigger… it’s a matter of tradeoffs… which I did consider… and then ignored.
Simply put, if FP loaded all the data into memory before rendering the page, your browser would sit and wait much longer than now.