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

Discussion in 'Python' started by Shawn McElroy, Sep 14, 2012.

  1. 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 alsoneed 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 toshow 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 itmore 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
    Shawn McElroy, Sep 14, 2012
    #1
    1. Advertising

  2. Shawn McElroy <> writes:

    > ...
    > So I need to find a way I can implement this in the best way...


    It is in general very difficult to say reliable things about the "best" way.
    Because, that depends very much on details.

    My former employer has created a combo destop/online application
    based on "Zope". "Zope" is a web application framework, platform independent,
    easily installable, with an integrated HTTP server. It is one of
    the natural choices as a basis for a Python implemented web application.
    To get a desktop application, application and Zope was installed
    on the client system and a standard browser used for the ui.

    The main drawback of this scheme came from the limitations of
    the browser implemented ui. It has been very difficult to implement
    "deep integration" with the desktop (e.g. "drap & drop" in and out of
    the application; integration with the various other applications
    (Outlook, Word, ...)) and to provide "gimicks" provided by the
    surrounding environment. Thus, after 8 years, the application started
    to look old style and the browser based ui was replaced by a stand alone
    desktop application that talked via webservices with an online
    system (if necessary).

    Thus, *if* the ui requirements are fairly low (i.e. can fairly easily
    be implemented via a browser) you could go a similar route. If your
    ui requirements are high, you can replace the browser by a self
    developped (thick) ui application that talks via an
    abstraction with its backend. Properly designed, the abstraction
    could either be implemented by direct calls (to
    a local library) or by webservice calls (to an online service).
    This way, you could use your client application both for the (local)
    desktop only case as well as for the online case.


    Your description (stripped) suggests that you need special support
    for "offline" usage. The is separate functionality, independent of
    the desktop/online question. For example, highly available distributed database
    systems must provide some synchronization mechanism for resynchronization
    after temporary network connectivity loss. Another example:
    transactional systems must not lose transactions and
    can for example use asnychronous message queues to ensure that
    messages are safely delivered even in the case of temporary
    communication problems or failures.

    Thus, look at these aspects independent from the desktop/online
    szenario -- these aspects affect any distributed system
    and solutions can be found there. Those solutions tend to be
    complex (and expensive).
    Dieter Maurer, Sep 14, 2012
    #2
    1. Advertising

  3. 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, andif 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 bea 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 toget 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 wayI 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 appthat 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 somecases, the reason I need a desktop implementation, is because the end userstill 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 updifferently. 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 domainas 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 howto best go about it, so I was hoping to get some ideas and input. Should Ido 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
    Shawn McElroy, Sep 14, 2012
    #3
  4. Shawn McElroy <> writes:
    > ...
    > 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.


    In my szenario you have a standard browser as (thin) client and
    Python only on the server side. In my szenario, the server could
    run on the clients desktop -- however, it ran there as a "service",
    i.e. not in "user space". My knowledge about Windows
    is limited. I do not really know whether a Windows "service" can
    fully interact with applications running in the "user space" and
    what limitations may apply.
    Dieter Maurer, Sep 15, 2012
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. TC
    Replies:
    4
    Views:
    644
    JohnnyAppleseed
    Feb 7, 2005
  2. RP
    Replies:
    2
    Views:
    517
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=
    Aug 19, 2007
  3. Alex Bryan

    Connecting a Desktop App to a Web App

    Alex Bryan, Jun 22, 2008, in forum: Python
    Replies:
    0
    Views:
    215
    Alex Bryan
    Jun 22, 2008
  4. dthmtlgod

    Fill Combo Box based on another Combo Box

    dthmtlgod, Nov 16, 2005, in forum: ASP General
    Replies:
    1
    Views:
    570
    Bob Barrows [MVP]
    Nov 16, 2005
  5. SM
    Replies:
    2
    Views:
    356
Loading...

Share This Page