How to implement a combo Web and Desktop app in python.

[Shawn McElroy]

This does help. I have not determined if I will make a native UI for the desktop yet. To start I just figured I would use the web based interface, and if needed, use something like qt, or wx. As for the ability to drag items into the user interface, there are javascript libraries that can handle that now, which triggers an upload of that file. So I dont think that would be a large issue. For example, minus.com does this really well with file uploads (mostly image sharing). 

Although you are correct in the aspect of having 'real' OS level integration. Being able to communicate with other apps as well as contextual menus. Although, could I not still implement those features from python, into the host system from python? There are also tools like 'kivi' which allow you to get system level access to do things. Though im not too sure on how far that extends, or how useful it would be.

as it stands now, I plan on having the 3 layers of my app. core, apps, and presentation. the core would go on both web and desktop and has no UI. the apps add on functionality to the core, based on what the app does. This way I can distribute a single app, without the others. And the UI, will be different based on platform. web/mobile will just be html/css, and desktop, will likely end up being something like qt/wx. 

Thanks.


On Thursday, September 13, 2012 5:20:48 PM UTC-7, Shawn McElroy wrote:
> I am somewhat new to python. I am still learning it. I am starting an app that I ma not quite sure how to best implement it.
> 
> 
> 
> In the grand scheme, there will be 4 apps total. There will be a core shared between them that allows them to easily talk to each other (ill explain) and communicate with a database, as well as redis for pubsub events. I also need things to work on both web, and desktop. So i will likely have to keep the UI and the core of each app in their own separate apps entirely. The main core on the web will be a REST interface with proper content negotiation, depending on what is requested.
> 
> 
> 
> Normally, if the desktop is online, you may think "If you have a good rest interface, this makes the desktop version pointless". While true for some cases, the reason I need a desktop implementation, is because the end user still needs to be able to use the app while there is no internet connectivity. For example, an in store POS system. They would still need to process transactions like cash while offline, and they would also need access to their inventory. This is also good for intermittent connection problems, and for speed. So they don't have to worry about networking issues to do things. For this reason a local database is also needed. And when online, it keeps in sync with the remote database.
> 
> 
> 
> So I need to find a way I can implement this in the best way, to help prevent code duplication, and reduce the amount of time it takes to get into production. If possible, I would like to use some kind of built in webkit for desktop as well, so users have the same experience both online and locally. So i would likely need to package a webserver as well (tornado/gunicorn?)
> 
> 
> 
> If it was entirely online, I see how I could implement this, but when needing to have a desktop version, I feel like I would need to split things up differently. Here is so far, how I would think that I need to structure everything.
> 
> 
> 
> Core: this is the CORE api to talk to the server, and interact with the systems. I should be able to do most things using this interface, and the individual apps may (or may not) add onto this for specific functionality.
> 
> 
> 
> App: this is the individual apps. going along with my example, these could be the actual POS interface, a shopping cart, product catalog/inventory management, and an admin/backend that would tie into everything and be able to show things like product/customer stats and so on.
> 
> 
> 
> Presentation: the actual user interfaces for each app.
> 
> 
> 
> I also feel like I should put it all into one app, bundled, and only split up the ui based on web vs desktop. The different 4 apps may also be at 4 web addresses. such as:
> 
> 
> 
> http://main.com (would probably include the admin app)
> 
> http://pos.com
> 
> http://products.com
> 
> 
> 
> so what is avaiable to the end user, will also be dependant on the domain as well. If they are all on one core, with only the UI separated out, the rest interface would likely be on all of them and only allow things based on what app you are looking at. Unless you are on the master domain where everything is allowed. 
> 
> 
> 
> I understand this is a complex question about implementation, and could be philosophically different depending on the developer. But im not sure how to best go about it, so I was hoping to get some ideas and input. Should I do it an entirely different way?
> 
> 
> 
> Currently for the apps themselves, I am looking at using either flask, bottle, web2py, or pyramid. I need to understand how I am going to implement it more before I choose a framework. Django is nice, but it doesnt seem to fit what I need to do. There are rest api plugins available for it, but if the core of my app is based on REST, it seemed to make more sense to start with something that has REST built into the core of the framework. 
> 
> 
> 
> Any input or advice is much appreciated. Thanks.
> 
> 
> 
> - Shawn McElroy