On Tue, 04 Oct 2011, Peter J. Halliday wrote: > The speed of bottle itself means we should look into whether it has > the ability to override route and if so how. Also look into the extras > you get. How's the developer support. > > Impressive framework.
I like Bottle as well, it is small and very fast. However, it does not come with lots of goodies, so I'm afraid it would be too light for our needs, we would have to enrich it here and there. There is Bottle-Werkzeug plugin we could use, but in this case why not to look rather in the Flask direction, since Flask/Werkzeug are both done by the same author, so their integration is native and therefore better than Bottle/Werkzeug's combination? I'd consider it to be strategically better to look in the Flask/Werkzeug combination rather than in the Bottle/Werkzeug combination, in order to be better future-proof. This kind of thinking. (BTW, I've read somewhere that there were attempts to merge Flask and Bottle, which would seem to make perfect sense to me, but the author of Bottle did not want to depend on something as big as Werkzeug, so nothing concrete happened with merging, due to philosophical differences of approach. So chances are that Bottle will remain small like this, while pluggable into stuff like naked Werkzeug, albeit not done by the same author.) For these reasons I'd rather favour to look in the Flask direction rather than in the Bottle direction. E.g. why don't we check what Armin's position is about having alternative URL routing? That said, another consideration is that out-of-the-box Flask may be perhaps not enough for our other needs still(?) in which case we may end up wrapping more of naked Werkzeug stuff anyway. So we could craft something ourselves and contribute it back. To be seen. Best regards -- Tibor Simko
