On 11 April 2018 at 11:39, Chris Dent <cdent...@anticdent.org> wrote:
> On Tue, 10 Apr 2018, Michael Johnson wrote: > > I echo Ben's question about what is the recommended replacement. >> > > It's a good question. Unfortunately I don't have a good answer. My > involvement in WSME is simply the result of submitting some bug fixes > in early 2015 and there being no one to review them. Lucas Gomes and > I were pressganged into becoming the sole core reviews for a project > that was already languishing. > > A short answer could be this: There doesn't have to be a > replacement. There are people in the community who are active users > of WSME, if those people would like to become maintainers of WSME, > Lucas and I can make those people core and help them to shepherd the > project to an active state. It may be that nothing really needs to > change. The reason this is coming up now is because a code change > was proposed that failed the gate because for unrelated reasons (the > pep8 python3 thing mentioned elsewhere). If the existing feature set > is sufficient the only real work to do is to keep those features > working as we move to python3. > I would like to see us move away from WSME. I'm not sure I have time to drive an effort in finding a replacement (and migration path) but I would certainly like to help. > > Any volunteers? > > For new projects, I think the standby is Flask + jsonschema. They > are both boring and common. > > I know some people really like django REST framework, but it appears > to have lots of magic and magic is bad. > > The longer answer is just opinion so if the above is enough of an > answer you can stop here before I go off on a ramble. > > I've never really been all that sure on what WSME is for. It > describes itself with "simplifies the writing of REST web services > by providing simple yet powerful typing, removing the need to > directly manipulate the request and the response objects." This is > pretty much exactly the opposite of what I want when writing a web > service. I want to be closely aware of the request and response and > not abstract away the details of HTTP because those details are what > makes a web service useful and maintainable. So I tend to avoid > typing systems like WSME and object dispatch systems like pecan in > favor of tools that are more explicit about the data (both headers > and body) coming in and going out, and that make the association > between URLs and code explicit rather than implicit. > > That is: you want to write code for the API layer so that future > maintainers of that code find it easy to trace the path through the > code that a request takes without having to make a lot of guesses or > de-serialize (in their heads) an object inheritance hierarchy. > > Flask can do that, if you chose to use it that way, but like many > tools it also allows you to do things in confusing ways too. > > I personally don't think that consistency of web framework across > OpenStack projects is important. What's important is: > > * The exposed HTTP APIs have some degree of consistency (that is, > they don't have glaring differences in grammar and semantics). > * The code is low on abstraction and high on scrutability so that > future maintainers aren't scratching their heads. > * Any frameworks chosen (if any) are maintained by the broader > Python community and are not OpenStack snowflakes. > > Committing to any particular framework is the same as committing to > being wrong and calcified in some fairly short amount of time. > > Who wants to volunteer to help maintain WSME? > > > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
