On 29/09/2014 11:48 PM, "Marcus Ottosson" <[email protected]> wrote: >> >> It makes no sense to spin up a local web server on every machine, using the development server. > > Sorry, I’m talking about running a single instance of Flask on a single computer, thus exposing this IP and port and have other computers connect to it. Like I would assume nginx would do, but wrapping a Flask instance too, is that right? > There we go. Exactly. The development server is good enough for testing but generally not up to the task of server multiple clients. uWsgi will let you run your Flask code as an application, and handles stuff like multiple workers and being able to roll your Web service updates without downtime. nginx is the httpserver that can sit in front and reverse proxy to your uWsgi application. It can do stuff like load balancing between more than once instance of your app, and is really strong at caching and serving static content without needing to constantly make your application service do the work.
So ya you spin up your single application server and all your client machines talk to it. Where or not it stores any state behind the scenes is of no consequence to the clients > > > On 29 September 2014 11:15, Justin Israel <[email protected]> wrote: >> >> >> >> On Mon, Sep 29, 2014 at 11:00 PM, Marcus Ottosson <[email protected]> wrote: >>>> >>>> A database doesn’t have to mean a big heavy beast that sits next to your application. >>> >>> I suppose not, but doesn’t it introduce an additional interface for users if they interact with is using something like SqlAlchemy? Having one in the background for concurrency and state seems fair. >> >> That interface wouldn't be addition nor exposed directly to your users (ideally). The point of the database is to store things persistently and to provide robust ways for querying against it, where it can be optimized for fast access. Your own application might be the one to use sqlalchemy to interface with your database, and you would expose an API to the actual users that controls their access. >> >>>> >>>> A few of those illustrations you made are constructed oddly. There shouldn’t be a database between your plugin and flask (and I am not sure that was implied as a suggestion)… >>> >>> No, I’m sure it wasn’t, just putting it out there for clarity. Which other illustration did you find odd? >> >> >> Well there were two illustrations that depicted a database sitting between the plugin and a flask instance, which I didn't understand. >> >>>> >>>> You have to host it with something, which is most commonly uWSGI, fronted by nginx. >>> >>> Aah, did not know that. I expected Flask to run on a machine and other machines connecting to it’s development instance directly. What are the disadvantages of doing it this way? Maybe something I’ll need to read up on.. I’ve only briefly encountered nginx. >> >> >> Yea, I am not really understanding this architecture, which leads me to believe that maybe you do need to read up a little bit more on what you want to use Flask for. It makes no sense to spin up a local web server on every machine, using the development server. What is it for? Why can't the actual client tool do exactly what it needs to do directly, or everyone goes through a shared service that performs all of the actions on their behalf? Is it that you are trying to use Flask as a way to provide a user interface on each local machine? What is the reason you feel you need a web service on each local client? If you don't want a centralized service, then it would seem you just want a desktop application that does the actions directly. What kind of tasks will this local http service perform that makes you feel it is the right choice? For all I know, you have a good reason that I have just not yet heard. >> >> When I talked about uWSGI+nginx, that is just the common stack people like to use these days, when running a production Flask application (as a shared resource). uWSGI can handle a pool of instances of your application for improved concurrency. >> >>>> >>>> Sure. You just want a basic http service. You make an http request, and it does something and returns a response. Makes sense, and my assumption would be that you would have a Flask instance running on a server within a facility, and all of the client Pyblish libraries (through a plugin as you mentioned) would make requests to the service. >>> >>> At least, that’s what I’d expect. >>> >>> Thanks, Justin. >>> >>> Best, >>> Marcus >>> >>> >>> >>> On 29 September 2014 10:45, Justin Israel <[email protected]> wrote: >>>> >>>> A few of those illustrations you made are constructed oddly. There shouldn't be a database between your plugin and flask (and I am not sure that was implied as a suggestion)... >>>> >>>> On Mon, Sep 29, 2014 at 9:57 PM, Marcus Ottosson < [email protected]> wrote: >>>>>> >>>>>> I’m not familiar with Firebase, but I don’t think it is the same thing as sqlAlchemy. sqlAlchemy is an ORM, which gives you an object-oriented abstraction around a database using models. >>>>> >>>>> Ah, that makes sense. Thanks, Justin. >>>>>> >>>>>> It sounds like you want a single network web service running (a backend powered by either Django or Flask), and for it to provide the RESTful interface to your Pyblish clients? >>>>> >>>>> I think.. so..? From what I gather, you can communicate directly with a running instance of a Flask server, and I was thinking “why not just pass data to it directly then?” >>>> >>>> >>>> Flask is just any other web framework. You have to host it with something, which is most commonly uWSGI, fronted by nginx. For development purposes you can usually use the included development server to run it directly as a self-hosted instance. Then ultimately you end up with an http server. It is up to you to develop and expose http endpoints that could either be a view that delivers html/js, or purely communicates back and forth in json. REST endpoints tend to deal in json back and forth, with the URLs following a common structure and using GET/POST/PUT/DELETE/HEAD methods. >>>> >>>>>> >>>>>> If it isn’t meant to store real production data (as it may just be delegating out to other existing services), but you do want it to have some persistent storage, then it could use an sqlite database for storing state >>>>> >>>>> Using a database for data persistence is making too many assumptions. I can’t assume to have users upload their production data to a database unique to Pyblish. I’d rather have Pyblish expose data already available elsewhere, ideally reading from disk directly. >>>>> >>>>> In this early stage, the only information I’d like to pass along to Django/Flask are paths to the data I’d like it to display, along with perhaps a description of how to display it (“this is an image path”, “this is the source file” etc.) >>>>> >>>>> Do you think that would work? >>>>> >>>>> For persistence of the events themselves there might be a database or just a file. Nothing I’d expose to anyone as it would only be used in cases of Flask/Django restarting/crashing. >>>> >>>> I understand completely. You are saying Pyblish has no real publish/production data to deal with. It is purely a service. And the only data is might need to store is the internal state of thing (active tasks/operations, stats, config, caching, ...). A database doesn't have to mean a big heavy beast that sits next to your application. It could be something really small like sqlite, or various embedded key/value stores that just live within your application. An example would be if one guy is performing an operation, and another guy wants to list what is currently in progress. You would need some sort of store for your data (as temporary as it might be) so that multiple http requests can access the state. >>>>>> >>>>>> The only other thing I could guess you might have meant was to have a local Pyblish service on each host… but I highly doubt that is something you meant. >>>>> >>>>> Could you expand on this? >>>> >>>> Well, for a moment I thought you were suggesting that you wanted to run a flask instance on every client machine. But I couldn't understand the point of that, so I didn't give it too much thought after that. >>>> >>>>> >>>>> The way I pictured the communication is the same as browsing to any website. A one-off connection is made, and some data is transferred and received. There is no lasting connection between Pyblish and Flask/Django. >>>> >>>> >>>> Sure. You just want a basic http service. You make an http request, and it does something and returns a response. Makes sense, and my assumption would be that you would have a Flask instance running on a server within a facility, and all of the client Pyblish libraries (through a plugin as you mentioned) would make requests to the service. >>>> >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> >>>>> >>>>> On 29 September 2014 09:48, Marcus Ottosson <[email protected]> wrote: >>>>>>> >>>>>>> what type of communication you need from between Pyblish and Django directly? >>>>>> >>>>>> I think this is best answered by the animation and description here: >>>>>> https://github.com/abstractfactory/pyblish/issues/99 >>>>>>> >>>>>>> instead they both communicate to the database like this: >>>>>>> Pyblish -→ Database ←- Django/Flask >>>>>> >>>>>> Thanks Asi, this makes sense, but doesn’t this assume that this database is used for other things, other than Pyblish and this web frontend? >>>>>> >>>>>> Here is how I’m picturing communication currently. >>>>>> >>>>>> In which Pyblish doesn’t know about Flask/Django, but it’s plug-in does. Pyblish is only running plug-ins exposed to it at run-time and has no knowledge about what they do or how they work. This way, a plug-in can access the surrounding pipeline, including databases. >>>>>> >>>>>> If I understood your description, you meant to have a database inbetween plug-in and flask. >>>>>> >>>>>> The database is either unique to this particular Web Frontend for Pyblish, but you probably meant to have Pyblish communicate with your native pipeline database and for it to communicate with Flask. >>>>>> >>>>>> But wouldn’t that mean that you would have to “teach” your database about Pyblish? For example, when Pyblish - or rather, a Pyblish plug-in - connects and transmits information to your database, it would need to know to connect to the running Flask instance. >>>>>> >>>>>> That sounds ideal if you are building Pyblish as one of your tools that all depend on a single database. But for a standalone application that integrates into your pipeline, don’t you think it’s better to have your pipeline integrate at the plug-in level, and thus not require any knowledge at all about Flask or other Frontends supplied by Pyblish? >>>>>> >>>>>> # Psuedo-code >>>>>> import mypipeline >>>>>> import pyblish_flask >>>>>> >>>>>> class MyPlugin(pyblish_flask.Plugin): >>>>>> def process(self): >>>>>> # In this case, Flask integration is hidden away and accepts >>>>>> # data like a dictionary or what not. >>>>>> self.notify(mypipeline.data) >>>>>> >>>>>> Best, >>>>>> Marcus >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Marcus Ottosson >>>>> [email protected] >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. >>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOB%2BDONG8Xm_vBeaEtftvjU7AOWuVSs4AxPu8ofBp%3DPR8Q%40mail.gmail.com . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. >>>> To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1ASQyEE61%2BkZK%2BN3dAxMwAuV7XmMMn6oXbbogoibcD3A%40mail.gmail.com . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> >>> -- >>> Marcus Ottosson >>> [email protected] >>> >>> -- >>> You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBFu9OzW6Df-AsefiMBfWSC28-QHHz2n%3DmoUfzBGee6xg%40mail.gmail.com . >>> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. >> To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1ZAQTXUXbDj4eGjq9ULOFM-sh8Z3TWEmBmnQYu%3D_VCwA%40mail.gmail.com . >> >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > Marcus Ottosson > [email protected] > > -- > You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODxngFgVLp%3D9YEhOH-D0V-hn%3DXXqGY_hrqt2P%3D7Rd9K0w%40mail.gmail.com . > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA37zMG3PTZZKtVvG_YkztF%2BSNBaeebartUYumH3b7r1BQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
