Open Stack

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.

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