Am 26.07.2018 um 16:20 schrieb John Spray: > On Thu, Jul 26, 2018 at 11:44 AM Sebastian Wagner <swagner@xxxxxxxx> wrote: >> >> I wouldn't recommend using CherryPy for future mgr modules. On the other >> hand I don't see immediate need for us to take any action right now. >> CherryPy will continue to be OK for the dashboard. So, I have no real >> "call to action" or concrete suggestion, except for raising awareness. >> >> If you want to ask, if there are other frameworks, my response would be: >> "They're saying Flask, Tornado, Pyramid and Django are good frameworks >> nowadays." [5] > > I don't have strong preferences between the various frameworks, since > I've worked with a bunch of them and found that each had its own > quirks. Also, I don't think we need to decide on any framework in the near future. > The original use of cherrypy in mgr modules came from the > desire for its multithreaded server (with a bonus framework built in), > rather than any particular affinity for the actual application > framework piece. > > I always expect a certain amount of "build your own layer on top" when > building atypical web applications. Frameworks like Django will > always require some customisation when you're not building a typical > database CRUD app, whereas frameworks like Flask are intentionally > minimal and leave a lot of structure up to the application author. > > Looking at openattic, we have the "nodb" parts that were needed to > adapt Django to a database-less application -- a sensible design, but > also an example of some necessary "fighting the framework". I have Django is not designed to be used without a database. Nodb disguises as a database table in order to e.g. allow using django-restframework's input validation. > had the same experience in the past when working on similar > applications -- the api->model piece is usually somewhat custom, > depending on what the models really represent in the system you're > managing. > > IME there are two kinds of framework pain: the kind that you can fix > and mostly forget (e.g. monkey patching the SSL bits, writing a > wrapper for handling status codes differently) and the kind that > continue to impact everyday development. The second kind is the worse > kind -- do we have issues like that? 'There is no need to move to a different framework. CherryPy will continue to be OK for the dashboard. > > John > >> - Sebastian >> >>> [5] https://twitter.com/gvanrossum/status/955523132026101760 >> >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
