Network/multi-user program

[Chris Angelico]

On Tue, Jul 22, 2014 at 2:07 AM, Monte Milanuk <memilanuk at 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