Refactor web.py to make more generic

[acedrew]

Epic haha, I like Flask a lot as well, it makes sense to try to emulate, let me know how I can help with this.

[acedrew]

Thoughts on this? https://github.com/acedrew/volttron/commit/341bd6cfac050dbd5d0df373c6ab5e51cde39c00

[sheridaj]

The code you submitted along with #1388 works great for my purposes. Already forked your repo and am running with it!

[bbarcklay]

As @sheridaj indicates, we will use the refactor and WebResponse (thank you) but this discussion has me wondering:

• What are are the pros/cons of building our own WSGIApplication within Volttron rather than adopting an open source library like Flask? Is there a technical reason this is not possible/reasonable?

• What is the argument against hosting the WSGIApplication within a Volttron agent so that requests intended for this agent do not need to travel back and forth across the bus?

I'm not suggesting a change here so much as I am wanting to understand the design philosophy behind these decisions. I'll contribute the pros/cons that I'm aware of:

Open Source WSGI Library (eg Flask):

Pros:

• Widely deployed, heavily tested
• Well documented and understood by developers
• Rich feature set - routing, variable rules, reverse urls, sessions, etc.
• Less new code to write

Cons (needs help):

• Another dependency
• (?) Technical reason why it cannot be used within Volttron
• (?) More complex than is required
• (?) License issue

Agent hosting of WSGI Application (rather than Volttron/MasterWebService):

Pros:

• Avoid message bus traffic that is destined for single agent (eg all SEP2 traffic)
• Enable use of 3rd party library (like Flask) - Could create a abstract WebAgent class
• Distributes workload, offloading main volttron process

Cons:

• Need to figure out how to manage ports across agents
• Connecting applications need to know correct port
• (?) Security issue

[acedrew]

I'm a little nervous about Flask's Context Globals in a platform as complex as Volttron. If Volttron had been built around Flask from the ground up, it would be a different story, but I'm afraid with multiple agents using the same Flask App, things could get really complicated and make things even more non-deterministic.

Flask also does not provide what they consider a production ready implementation of a WSGI server, so we would still have to use the main process as the underlying server, or spin up a new, separate HTTP server process. (this could be an option in the future for low power nodes with high levels of HTTP workload)

I am not a Lawyer, but the Licenses seem to be compatible.

I don't think there's anything preventing you from hosting an independent web application in your agent currently, there certainly could be better tooling around that eventuality, if it's considered to be a strong need in the ecosystem.

I would think if you are implementing an external interface for a specific communication standard over HTTP, you may very well be better off including Flask in your agent and creating your own server context using the underlying py4ws WSGI component.

[craig8]

Yeah I agree with @acedrew there is absolutely nothing preventing you from ignoring the platforms web implementation and just going with Flask or any other third party web application, or for that matter dependency. Though I would be hesitant to put it in the core repository.

The web.py service actual started out as tornado for just VolttronCentral. It has been moved into the base so that it is very simple to hook up other agents into the web and talk on the message bus. One of the things I eventually want to do is have a central auth kinda login architecture...will see if that makes it in sometime or not.

:)