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. 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? 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. 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. >>> [image: Inline images 2] >>> >>> 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. >>> >>> [image: Inline images 3] >>> >>> If I understood your description, you meant to have a database inbetween >>> plug-in and flask. >>> >>> [image: Inline images 4] >>> >>> 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. >>> >>> [image: Inline images 5] >>> >>> 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-codeimport mypipelineimport 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 >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOB%2BDONG8Xm_vBeaEtftvjU7AOWuVSs4AxPu8ofBp%3DPR8Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> 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 > <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1ASQyEE61%2BkZK%2BN3dAxMwAuV7XmMMn6oXbbogoibcD3A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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.
