Open Stack

On 11 April 2018 at 11:39, Chris Dent <cdent+os at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180411/0845ff5d/attachment.html>