On Tue, Jul 22, 2014 at 2:07 AM, Monte Milanuk <memila...@invalid.com> wrote: > So I guess I'm asking for advice or simplified examples of how to > go about connecting a client desktop app to a parent/master desktop app, > so I can get some idea of how big of a task I'm looking at here, and > whether that would be more or less difficult than trying to do the > equivalent job using a web framework.
Easier way: Don't have a "master desktop app", but instead have a master database. Since you're posting this to python-list, I'll assume you currently intend writing this in Python; you can make a really simple transition from single-user-single-desktop to a networked system, although of course you'll want to think in terms of multiple users from the start. All you need to do is pick a database engine at the top of the script. As a general rule, I would say that it's okay to have more complicated installation instructions for a more demanding job, so you can have the single-user setup done with SQLite3 (no need to install a database and worry about passwords), but for the multi-user setup, they have to install (say) PostgreSQL on a single central server, and then possibly key in some authentication on each client (or even maybe not, depending on how much you trust the LAN - you did say there's no internet exposure). This is going to be comparable difficulty to setting up a centralized web server, but with the advantage that you can short-cut the whole thing when it's to be used on only one computer (not really possible with a browser-based system). Your UI would, obviously, be absolutely the same for both scenarios - it'd be all the same code, doing exactly the same things. (Obviously you'd have to make sure your SQL isn't specific to either engine, but that's easy enough. You won't warp your code much around that.) The only difference would be if you have to worry about update conflicts and other inherently multi-user issues, but ultimately there's no difference between the multi-user scenario where nobody else happens to be doing anything, and the dedicated single-user scenario. So, how big a task is it? If you're already familiar with the Python databasing API, and at least broadly familiar with a multi-user DBMS like PostgreSQL, and especially if you already know the important aspects of coping with simultaneous users, then this will be pretty easy - much easier than working it into a web browser. (And you'd need to worry about the issues of simultaneous users anyway. There's really no difference on that.) In terms of setup complexity for your users, it's *possible* that you could develop a low-performance web server that would be easier to deploy. You'd just need to either embed an HTTP server in your Python script, or use a framework that includes one; and if you make it single-threaded (ie all requests are serialized), you could use SQLite for the database back-end. In contrast, I'm suggesting a central database, which has to be installed and configured (most databases won't, by default, accept connections from anyone but localhost), which at very least will require a bit more chugging (you can automate all or at least most of it, but it'll still take time to install). The advantages are that you can trust your code (because it's all the same everywhere), and yet you have an extremely light single-user mode, plus your UI is flexible - you're not restricted to a web browser, you can build an actual application with whatever UI you like. And, in fact, you could have several different UIs, if you wanted to, because it's the database that's king. Maybe it'd be helpful to have a really REALLY cut-down UI for the basic data entry, with no clutter from the admin functions. It'd all work fine. (And you could add that later, without breaking anything.) It is, of course, possible to write a desktop application that can be remotely scripted for data entry. But I don't think it's necessary. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
