Separate the flask slicer serve functionality from cubes.server into a separate module.
Reasons:
allow other server type implementations, such as protobuffer or thrift kind of server.
make the core Cubes package more light weight
decrease dependency complexity
open possibility for separate maintainer
Changes needed:
have a server extension type
define server extension API
add server loading mechanism
add type into [server] section of slicer.ini
Recommended external server module naming: cubes-server-TYPE such as cubes-server-FLASK for stand-alone packages with server implementations. It is just a convenience, since we are going to use entry_points anyway.
Default server type should remain flask and will not have to be specified explicitly in the slicer.ini.
Separate the
flask slicer servefunctionality fromcubes.serverinto a separate module.Reasons:
Changes needed:
serverextension typeserverextension APItypeinto[server]section ofslicer.iniRecommended external server module naming:
cubes-server-TYPEsuch ascubes-server-FLASKfor stand-alone packages with server implementations. It is just a convenience, since we are going to useentry_pointsanyway.Default server type should remain
flaskand will not have to be specified explicitly in theslicer.ini.