This is yet another big step for Cutelyst, this release bring several important fixes to the last version, and stabilizes the API a bit more. So far I have successfully deployed 3 commercial applications build on top of Cutelyst + Grantlee5, and the result is great.
If you don’t know Cutelyst yet it’s a Web Framework allowing you to build web applications using Qt, for more info check (this blog and) our website/wiki which is still work in progress: http://cutelyst.org or join #cutelyst on freenode
This release brings the following improvements:
- Further speed improvements by simplifying several code paths and improving the dispatcher logic was an overall of 15% speedup
- Added an API to enable Grantlee template caching which greatly improve speed when using Grantlee templating
- Improved Query and Body parameters to allow for properly dealing with posts that contains the same field id multiple times
- REST API – Since 0.1.0 I was asked about supporting REST, and since I needed it for another project that I got involved the support landed early, the behavior is the same as Catalyst::Action::REST which allows you to easily add a foo_DELETE method which will get automatically called if the request method is DELETE for example.
- Added a Credential HTTP plugin to handle Basic HTTP (and in future Digest) authentication
- Added support for Authenticate and ProxyAuthenticate basic parsing on the Headers class
- Finished Context::uriFor() methods that allows for easily building an URI.
- Added a method to do a DNS PTR lookup to get the hostname of the client
- Added a C_PATH to more easily set the matching part of the path (thanks to Dan Vrátil)
- Fixed a few memory leaks
- Fixed a crash if the body wasn’t set
- Fixed uWSGI body buffered device
- And a lot of other misbehaviors found on post release…
For the next release I hope to be able to port the Catalyst tutorial to the Cutelyst equivalent, and finish a few other API changes.
As before the API is unstable but don’t be afraid of playing with it, most changes will simply require a rebuild of your application.
Another mostly bugfix release to make packagers and users happy :)
Sadly I needed to change the direction of where I put most of my efforts, which means that I’m focusing more on getting some commercial products done to get bills payed (as fundraising campaigns doesn’t work well all the time). For a long time I’ve been trying to polish everything I could to have the desktop I wanted, but recently I realized that the way I was doing it would never work, first because I’d need to convince people to think like I do, second because no one in free software writes stuff for free, and this took me a lot of time to realize.
Almost everyone writes stuffs for himself, otherwise there’s no pleasure, so unlike companies you can’t tell a free software developer to work on something he/she doesn’t like, which is one explanation for why most of the projects I started received very little help, an important help (don’t get offended) but still I don’t have active developers in Apper*, print-manager, libudisks-qt, colord-kde, aptcc* (* Matthias and some Fedora dudes have added some nice features) and a few others. The KDE community has always been kind to notice my code mistakes or even fix the code by themselves but featurea are a different matter.
Don’t worry I’m not moving to OSX :P
But for a long time I’ve been building in my mind the Workspace that I want, and with Wayland I realized It would be somehow easy to achieve what I want when speaking of a desktop shell, which would basically be a shell where all widgets are independent process, where a QML compositor just properly place it’s surfaces, Aaron already covered the pros/cons of such approach however I’m stubborn …, I know it’s a huge task to start a new workspace/DE whatever and I’m not going to do that right away (tho I have played with some Wayland code already), instead I’m trying to get my commercial software to pay for it, which might take quite some time :P
So I just would like to maybe catch someone that cares for some of these stuff I maintain and give a hand, specially on KF5. I don’t yet have KF5 packages ready in my distro and as I said I’m focusing on other stuff, I’ll still maintain them and eventually port them by myself but I’m mostly in bugfix mode :P except for Cutelyst which is a project I’m actively working on as I need it for the web stuff I’ve been doing :)
A good start is porting print-manager to KF5 which should be rather easy.
And here is hopefully the last Qt4/KDE4 based Apper :P
Release early, release often has never been my strength especially since I don’t do a fair scheduling of all the projects I’m involved…
So since I was in need to better polish Cutelyst I took more time on it, and the result is great, around 100% speed up and a few new features added.
Cutelyst uWSGI plugin now has support for –thread, which will create a QThread to process a request, however I strongly discourage its usage in Cutelyst, the performance is ~7% inferior and a crash in your code will break other requests, and as of now ASYNC mode is not supported in threaded mode due to a limitation in uWSGI request queue.
Thanks to valgrind I managed to make a hello world application from 5K request per second on 0.2.0 to 10K req/s on 0.3.0 on an Intel Core2Duo 2.4Ghz (or 44K req/s on an AMD Phenom II 965 x4 3.4Ghz), however if you enable Grantlee templating you get around 600 req/s so if I happen to have time I will be looking into improving its performance.
Response::body() is now a QIODevice so you can set a QFile* of something else and have Cutelyst to send it back.
The 0.3.0 tarball can be downloaded here
Have fun :)
Five months ago I announced the very first release of Cutelyst, a web framework powered by Qt 5. Time passes and I started shaping my real world applications written with it, I should probably release a newer version earlier but it’s not very nice to keep releasing API that changes a lot, however next version (0.3.0) will still contains API changes. What changed from 0.1.0 to 0.2.0:
- I have setup a documentation website http://cutelyst.org
- I started a WordPress like blog written with Cutelyst https://gitorious.org/cutelyst/untitled this right now is a nice example app, if you like it please help :)
- Changed the API to expose the forked behavior thus being able to setup database connection in each new process avoiding a mess
- UWSGI got a patch to deal with workers that don’t want to work, in other words when something on post-fork fails like reaching the dababase connection limit the worker can exit and won’t be restarted.
- A bunch of bugfixed of course
- Make use of categorized logging (ie qCDebug)
- Allow for UWSGI to restart the application as soon as your application .so file changes, this greatly improve development speed :)
- Encapsulated the post body into a QIODevice subclass on UWSGI engine this means a QFile is –post-buffering limit is reached, or a custom IODevice that deals with the request memory buffer
- A parser to get uploaded content “multipart/form-data” which is fast and can work with lots of data
For the next version I’ll try to get a properQt loop integration. Download here Have fun!
This new release doesn’t bring new features but it’s an important one since it supports PackageKit 0.9.x API, also this is the first release which uses the first 100% async calls on PackageKit-Qt.
Making Pk-Qt sync-free wasn’t so complicated but since I had to rethink the API the client code of Apper also needed to be adapted, I must say that I was lazy sometimes and just created a QEventLoop in Apper to wait for the reply… and this basically means that there will be new bugs in Apper, and hopefully some will be fixed.
It’s interesting that using DBus doesn’t means the code talking to it is async, the proxy classes generated by qdbus2cpp do a blocking call everytime you ask for a property, so you have to avoid it and do a GetProperties call which returns to a callback, although this worked well for PackageKitQt I failed to do the same for libnm-qt, and that is because it’s nearly impossible to make it somehow reliable due to NetworkManager itself not using gdbus, so you can’t have a reliable snapshot of it, unless you do an introspection call which is also insane, so I prefer to wait for when they switch to gdbus :P
Apper 0.9.0 depends on Qt4, KDE4 libs and PackageKitQt 0.9.2.
I’m not giving it much attention lately since I’m slowly building Apper on Qt5 which will be using QtQuick2, as my time is short supporting this old version is mainly to make packagers happy :)
this is just a quick bug fix release, the last one depending on PackageKit 0.8 series, it doesn’t have new features apart from having some fixed support for appstream 0.6.
For the next 0.8.3 version PackageKit 0.9 will be required.
For more information you can look at the git logs.
Have fun :)
Three months ago Custelyst was started,
it was somehow a proof of concept to see if I could build something that could be used in the real world, but the more I progressed on getting all the pieces together the happier with the overall result I got. And the initial result is here today!
I have made a few benchmarks comparing some simple pages delivery using Django (python) and Perl Catalyst, and overall the time to first byte was around 3 times faster than both, comparing RAM usage it was like 2MB vs 50MB from the Perl version and 20MB of the Python one, the CPU time was also much smaller if compared to both which probably means it could handle more requests, but this isn’t a completely fair benchmark (as always) because there are several other things to measure…
Below I’ll try to clarify some doubts raised from my last post and what makes this new Web Framework unique:
But there is already QDjango and Tufao…
I didn’t know about these ones when I first started Cutelyst, but after taking a look at them, both misses a templating system (or integration with one), I also didn’t like the way one would register actions to be dispatched, IMO the way it’s done in Cutelyst is easier and nicer. And they doesn’t count with WSGI integration, they have their own HTTP parser/server. I also didn’t like looking at code :P
Why not DJango or any other well established framework out there?….
Apart from QDjango and Tufao there are no other (AFAIK) Qt based frameworks, there are indeed some C++ ones that I knew before but I didn’t like the way of doing things there, in fact when I started with Perl Catalyst I really liked how it was written. So in short I don’t know well enough other languages and I have no plans wasting my time learning other languages, I’d rather try to master at least one (although I know I’m far from it).
What’s in this release?
- Glad you asked (duh!)
- Production ready integration with uWSGI, meaning Cutelyst has a uWSGI plugin that will load your application (which will also be a plugin), and thus thanks to uWSGI it will have out of the box support for FastCGI, HTTP(s), uWSGI (protocol) and probably some other.
- ClearSilver templates integration, this templating system is written in C and it’s amazingly fast, but it’s also incredible limited to what you can do in the view.
- Grantlee (Django) templates integration, it’s used in KDE PIM to allow for easy templating of HTML, it’s slower than ClearSilver but offers much more fexibilities on your views, and since it’s also written in Qt the introspection comes for free.
- Complete Path dispatcher, which means if you Port a Perl Catalyst Application that was using Path actions it will work as expected. This dispatcher matches an url to a Q_INVOKABLE method depending on it’s signature, The Catalyst Chained dispatcher is not implemented yet.
- Session plugin, easy to use way of persisting data across requests, right now it’s done with a QSettings file, but integration with Redis and MongoDB are planned.
- Authentication plugin, allowing you to authenticate your users using different Realms/stores, currently a StoreMinimal is implemented which can be used mostly for testing purposes (ie on the code you add your users)
- StaticSimple plugin, allows for serving static content reducing the complexity of serving static content while developing your app.
If you are concerned about API/ABI stability I don’t promise it just right now it’s almost stable, probably 0.2 or 0.3 versions will have a promised stable API.
And yes, I have just put it on production http://serial.igloobox.com.br is running it right now (but the site is user restricted).
My plans now is to setup cutelyst.org with docs and examples, as well as writing a web blog, bug tracker and wiki based on it.