Creating a multi-tier client/server application

[Jeff]

Hello everyone. I've searched through the archives here, and it seems
that questions similar to this one have come up in the past, but I was
hoping that I could pick your Pythonic brains a bit.

Here's a broad overview of what I need to do: cross-platform, client-
side GUI apps that interact with a server backed by a database. I'd
also like the possibility of having a web interface for small portions
of the app. It will be a fairly complex system for managing personnel
(and training, performance reviews, etc.) and payroll, and I will
probably have about a year or more to write it.

None of this is written yet--actually, it's not even to the point of
specs yet, I'm just trying to learn the best way to do this *before* I
get to the specs. I want to plan this application out as thoroughly
as possible before writing any code, and I want to do it The Right
Way(TM), hence I have (hopefully) convinced my manager (and clients)
that Python is the way to go. I have a couple years of experience in
Python, but it's mostly been web apps (which I am thoroughly sick of
making, thanks to PHP) and simple CLI programs. Not sure if any of
that information helps, but I'm tired, so please bear with me.

The application definitely needs at least three tiers: client, server,
and DB. I want as little logic in the client as possible (if not
none), as there will be sensitive data in the DB. I also can't have
the clients connect to the DB directly, as it will need to only accept
connections on the local host. The client will probably be installed
on 50-100 machines, and will be used by several hundred people (yes,
they're sharing machines--the users will be computer lab consultants/
server operators/helpdesk employees, etc. and their supervisors), so
authentication (using LDAP) and authorization (using groups I will
define) will be very important. Also important will be automatic
updates of the client, which I figure I'll do by comparing version
numbers, then downloading an archive (egg, maybe?) of the latest
(compiled? byte-?) code.

I will probably make the GUI in wxPython, as that seems to be most
flexible and nicely cross-platform choice--but I am open to
suggestions. Not too worried about that one, though.

For the database, I'll use Postgres, because I love Postgres.
Probably not going to budge on that one unless anyone has any good
reasons to. I'd also like to use SQLAlchemy (because it is so nice),
but this is not a requirement (I can write SQL, but... SQLAlchemy is
so nice.) I'd like to use an ORM mainly because it would facilitate
code reuse for the (very simple) web interface, and other offshoot
tools down the line.

So, my real question (sorry for the all the exposition) is this: how
to do the networking? I'd really like to have the client send a
simple request to the server along the lines of "fetch this (or these)
object(s)", or "update this value in this object", then let the server
decide if the user actually is allowed to do so, and then make the
change in the database.

My first thought was XML-RPC, because I've used it before, and it is
so nice and clean--but then I can't send objects, which is really
rather crucial.

Then I looked at Pyro, which seems awesome, but I'm confused as to how
(if possible) I would use it with a DB. Would I have to figure out on
the client what SQL query to send to get the right objects? That would
kind of kill the separation of logic. And would it work at all with
SQLAlchemy (or any ORM for that matter)?

I looked at SOAP. It made me feel unclean. I looked at some CORBA,
at which point my eyes glazed over (possibly not CORBA's fault, I will
look at it again later).

I checked out Twisted, but there are so vastly many parts to it, that
I'm not sure where to even start.

I'm not ruling out writing my own simple protocol, but it seems like
I'd be reinventing a wheel that's already been reinvented countless
times.

So, all that said--any advice on how to do the networking? And on the
auto-update? For that matter, any advice on anything I've mentioned
(or haven't?) Please feel free to ask me to clarify anything, or tell
me if I'm being an idiot about anything.

Thanks,
Jeff

 

[Paul Rubin]

Here's a broad overview of what I need to do: cross-platform, client-
side GUI apps that interact with a server backed by a database. I'd
also like the possibility of having a web interface for small portions
of the app. ... any advice on anything I've mentioned
(or haven't?)

Why not do the entire app as a web app, completely bagging the client
side and just using a browser? It will help your deployment problems
a lot, and using https will help with security since it looks like the
app will be transmitting sensitive data. It also will simplify your
networking questions a lot since you're just writing a server.

See the big debate between Chris Mellon and me a few weeks ago about
web apps vs client gui apps. Yes you can get a level of
responsiveness from a client app that can't easily be done with a web
app. However, relatively few client gui business apps that I've
personally used really seem better than the equivalent things done as
web apps in the obvious way.

I would certainly prototype the app as a web app, and then think about
writing a client gui only if it was clear that usability would really
benefit from it. Even still, the server would still look like a web
server, translating xml requests into database actions and responding
with xml.

I want to plan this application out as thoroughly
as possible before writing any code,

There is a school of thought (sometimes associated with "extreme
programming") that this is more planning than you should really do.
Think of a cross-country automobile trip. Figure out the general
route you want to take, then get in the car and go, making low-level
decisions as you get to them, rather than trying to plan every gas and
rest and restaurant stop before you leave.

 

[Bruno Desthuilliers]

Paul Rubin a écrit :

Why not do the entire app as a web app, completely bagging the client
side and just using a browser? It will help your deployment problems
a lot, and using https will help with security since it looks like the
app will be transmitting sensitive data. It also will simplify your
networking questions a lot since you're just writing a server.
(snip)

I would certainly prototype the app as a web app, and then think about
writing a client gui only if it was clear that usability would really
benefit from it. Even still, the server would still look like a web
server, translating xml requests into database actions and responding
with xml.

I'd personnaly favor json, which is much more lightweight, perfect for
structured data, and widely supported.

Else, and however the client is implemented (rich client or web -
another possible solution being something based on the Mozilla platform,
but I have no working experience with it so I can't tell if it's a good
idea...), I'd second the suggestion to have a closer look at the http
protocol. There's no shortage of support for writing http-based server
applications in Python (given the context, I'd strongly suggest Pylons).

There is a school of thought (sometimes associated with "extreme
programming") that this is more planning than you should really do.
Think of a cross-country automobile trip. Figure out the general
route you want to take, then get in the car and go, making low-level
decisions as you get to them, rather than trying to plan every gas and
rest and restaurant stop before you leave.

Anyway, unless you're a genius with decades of working experience, you
can bet you'll make lots of mistakes in your "planning", mistakes that
you'll discover when implementing a probably over-engineered design. I'm
of course *not* advertising a cowboy-coding approach here, and
preliminary work is certainly mandatory for anything non-trivial, but
take care about what you really have to worry about here. AFAICT, you
seem to be on the right track so far (thinking about the possible
architectures given some already known requirements), but AMHE,
BigDesignUpFront just doesn't work, so don't overplan.

My 2 cents...

 

[Jeff]

Thanks for the quick responses.

I was really hoping to avoid an entirely web-based app, for a few
reasons, not the least of which is that I've been working almost
entirely on web apps for the past few years, and I am getting mighty
sick of it. A lot of that is due to the language (PHP, which I have
since grown to hate) I had to use. I've worked on a site for my self
in Python (using Pylons, actually--which is excellent) which was
vastly easier and more fun. But I'd really like to try something
different.

Now, of course, that's not enough reason to force such a thing onto my
clients (when I say clients, I mean the ones that are paying for this,
but they're really within my same department, so they actually have
working technical knowledge.) Some reasons for them would be (in no
particular order): 1) More responsive and user-friendly interfaces, 2)
Much better ability to sort, export, import, and print data (very
important), 3) Easier to "lock down" who's using the program by only
installing it on certain machines.

Paul, I've read through a bunch your conversation with Chris--for
simple applications, yes, you're right, why not use the browser? But
for a lot of this I have to agree with him (although I don't
particularly agree with his tone, but that's irrelevant.) This will
be a complex enough application that certainly simple HTML & CSS won't
be enough, and the thought of the sheer amount of AJAX trickery (yes,
trickery) that I'll need to use just to get it even *close* to the
usability of a desktop app is rather frightening. I've done plenty of
stuff with AJAX, and it certainly has its purpose, but it gets
incredibly bloated and fragile *very* quickly.

This application will be used by hundred of people (some of them will
be using it more or less constantly) across several departments in a
large university (Rutgers, if you're interested.) Because of that, it
needs to work, and last for years--with changes over that time, of
course, but no rewrites--a lot of their current systems are FileMaker
Pro databases... all I can say is, "the horror". They've used some of
these systems for the past *ten* years with their "databases" breaking
several times a *week*. Now, they want something that *works*.

Which leads me to the discussion of planning: if this were a basic
application for myself, I'd plan out the basic objects and database
tables I'd need, and how they should interact--maybe to some extent
what the user interface should work/look like. But I'd certainly be
flexible. In this situation, however, I have no such luxury.

This system will be used, often, to figure out how much people should
be paid (and then interface directly with the University's payroll
system), and store lovely things like SSNs, and will also have to have
somewhat crazy business logic to track when hourly workers are
eligible for raises, if they took enough training classes, etc. There
are a lot of people with a stake in this system, and I will need to
work with them very closely on how this should work, and they sure as
hell don't want any surprises. My manager even wants use cases (if
you've never had to deal with use cases, consider yourself a lucky,
lucky person) which I am going to attempt to argue as that is even
going *too* far.

So, long story short (too late), no Extreme Programming for me.
Hopefully, the amount of planning will be somewhere in between that
and the bureaucratic nightmare of documenting up front what each
module, class and function will do.

Thanks again for your advice--I really appreciate it.

 

[Bruno Desthuilliers]

Jeff a écrit :

Goldfish--thanks, I'll check it out.



I suppose I don't need to transfer objects, it just seems like it
would make it far easier (certainly less repetition of code)

Why so ???

 

[Bruno Desthuilliers]

Jeff a écrit :

Thanks for the quick responses.

I was really hoping to avoid an entirely web-based app, for a few
reasons, not the least of which is that I've been working almost
entirely on web apps for the past few years, and I am getting mighty
sick of it. A lot of that is due to the language (PHP, which I have
since grown to hate) I had to use. I've worked on a site for my self
in Python (using Pylons, actually--which is excellent) which was
vastly easier and more fun. But I'd really like to try something
different.

Now, of course, that's not enough reason to force such a thing onto my
clients (when I say clients, I mean the ones that are paying for this,
but they're really within my same department, so they actually have
working technical knowledge.) Some reasons for them would be (in no
particular order): 1) More responsive and user-friendly interfaces,

You could explore something like a custom-made GUI client app
communicating thru the http protocol with a web-server app. http is just
a protocol, and it doesn't necessarily imply using html and a browser...
IIRC, some GUI toolkits uses XML description files for the UI.

(snip)

3) Easier to "lock down" who's using the program by only
installing it on certain machines.

Not a very reliable security scheme IMHO !-)

(snip)

Which leads me to the discussion of planning: (snip)

This system will be used, often, to figure out how much people should
be paid (and then interface directly with the University's payroll
system), and store lovely things like SSNs, and will also have to have
somewhat crazy business logic to track when hourly workers are
eligible for raises, if they took enough training classes, etc. There
are a lot of people with a stake in this system, and I will need to
work with them very closely on how this should work, and they sure as
hell don't want any surprises. My manager even wants use cases (if
you've never had to deal with use cases, consider yourself a lucky,
lucky person) which I am going to attempt to argue as that is even
going *too* far.

So, long story short (too late), no Extreme Programming for me.

Extreme Programming doesn't mean "no preparation", and makes heavy use
of use cases. Of course you need to have some - hopefully accurate -
functional specs. The point was mostly along the lines of "don't try to
have full-featured detailed design before you start coding, because
chances are it will be wrong".

Hopefully, the amount of planning will be somewhere in between that
and the bureaucratic nightmare of documenting up front what each
module, class and function will do.

Which would be totally non-sensical. I don't believe anyone on earth
could come up with such a thing - done right - *before* the application
is written.

 

[Jeff]

You could explore something like a custom-made GUI client app

communicating thru the http protocol with a web-server app. http is just
a protocol, and it doesn't necessarily imply using html and a browser...
IIRC, some GUI toolkits uses XML description files for the UI.

That, or something similar, may be what I do. It would mean, however,
developing my own method for transferring objects across the network,
which, as far as I can tell, is what things like Pyro are supposed to
take care of.

Not a very reliable security scheme IMHO !-)

You are 100% correct. That will most certainly *not* be the only
means of security. There will be user authentication against a
central LDAP server, SSL for all connections, and possibly IP address
based blocking as well. I need to clarify what I meant (I didn't want
to bore everyone with the tedious details)--while this system will
mostly be used by supervisors/managers, the employees will also be
using it to sign into their shifts. The managers want the employees
to only be able to sign in from designated machines, while at the same
time they want them to be able to look up their schedules from a web
interface, but *not* use that to sign in. That wasn't the best point,
but I think there's something to be said of the *perceived* security
of desktop vs. web apps.

Extreme Programming doesn't mean "no preparation", and makes heavy use
of use cases. Of course you need to have some - hopefully accurate -
functional specs. The point was mostly along the lines of "don't try to
have full-featured detailed design before you start coding, because
chances are it will be wrong".


Which would be totally non-sensical. I don't believe anyone on earth
could come up with such a thing - done right - *before* the application
is written.

I'm not looking to layout how the GUI should look, or even how
individual parts of it should work. What I need to do, though, is
write very detailed specs with my clients on the data that will be
used, and plan out as thoroughly as possible the architecture of the
project as far as tiers and such. I don't have much choice in this
aspect, sadly. But, in my experience, the more detail (and agreement
on those details) I have up front, the less painful the rest of the
process will be.

Thanks again!

 

[Goldfish]

Perhaps Spring Python can help you out (http://springpython.python-
hosting.com). It reuses technologies like Pyro for remoting, offers
database templates, has a plugable security component, an AOP solution
should the need arise, an IoC container, and has a couple of web-app
demos using CherryPy. Of course, you can use whatever web stack you
want. I just picked CherryPy to demo things.

Each component of Spring Python is optional, and you can use it
through the IoC container, or programatically. This might help you
leverage development of an enterprise app.

BTW, I have plans to implement a wxPython front end sample app. I just
haven't done it yet.

Good luck!

 

[Bruno Desthuilliers]

Jeff a écrit :

That, or something similar, may be what I do. It would mean, however,
developing my own method for transferring objects across the network,

Why transfering "objects" ? You only need to transfer data.

(snip)

 

[Jeff]

Goldfish--thanks, I'll check it out.

Why transfering "objects" ? You only need to transfer data.

I suppose I don't need to transfer objects, it just seems like it
would make it far easier (certainly less repetition of code) to
program the client-side app.

 

[askel]

Goldfish--thanks, I'll check it out.



I suppose I don't need to transfer objects, it just seems like it
would make it far easier (certainly less repetition of code) to
program the client-side app.

If you prefer to deal with RPC-like protocol, take a look at Ice by
ZeroC (http://www.zeroc.com/).

 

[David Bolen]

reasons, not the least of which is that I've been working almost
entirely on web apps for the past few years, and I am getting mighty
sick of it. A lot of that is due to the language (PHP, which I have
since grown to hate) I had to use. I've worked on a site for my self
in Python (using Pylons, actually--which is excellent) which was
vastly easier and more fun. But I'd really like to try something
different.

To contribute a data point against your original question - I've a similar
(structurally, not functionality) system I completed recently.

Without trying to get too mired in the thick client v. web application
debate, there were a handful of points that decided me in favor of the
thick client:

* Needed to automate QuickTime viewer for video previews and extraction
of selected frames to serve as thumbnails on web approval page.
* Needed to control transfers to server of multiple very large files
(hundreds of MBs to GBs at a shot)

But assuming a thick client, in terms of your original question of
components to use, here's what I've got. My primary networking component
is Twisted.

The pieces are:

Client (OS X Cocoa application):

* PyObjC based. Twisted for networking, Twisted's PB for the primary
management channel, with an independent direct network connections for
bulk file transfers. (I needed to go Mac native for clean integration of
QuickTime UI elements including frame extraction to thumbnails)

Server:

* Twisted for networking. PB and raw connections for clients, web server
through twisted.web. Genshi for web templating, with Mochikit (might
move to JQuery) for client-side JS/AJAX. Twisted for email transmission
(email construction using normal Python email package). Small UI
front-end module (Cocoa/PyObjC).

The client accesses server-based objects through Twisted PB, which for some
of the server objects also control session change lifetime (transactions).
So at least in my case, having a stateful connection from the client worked
out well, particularly since I needed to coordinate both database changes
as well as filesystem changes through independent file uploads, each of
which can fail independently.

Right now a single server application contains all support for client
connections as well as the web application, but I could fracture that (so
the web server was independent for example) if needed.

For the client, I package it using py2app, and put into an normal Mac
installer, and distribute as a dmg. If it were a Windows client, I'd
probably wrap with py2exe, then Inno Setup. The server's web server has a
restricted URL that provides access to the DMG. The client has a Help menu
item taking users to that URL. Clients are versioned and accepted/rejected
by the server during initial connection - from the server side I can
"retire" old client versions, at which point users get a message at signon
with a button to take them to the download page for the latest DMG.

So right now upgrades are executed manually by the user, and I can support
older clients during any transition period. I may provide built-in support
for automatically pulling down the new image and executing its installer,
but haven't found it a hardship yet. I probably won't bother trying to
automate smaller levels of updates.

-- David

 

[Paul Rubin]

I was really hoping to avoid an entirely web-based app, for a few
reasons, not the least of which is that I've been working almost
entirely on web apps for the past few years, and I am getting mighty
sick of it.

If you've done any gui programming, you'll know that it's even more
tedious and time-consuming than web programming. At least the way I
do web stuff, I'm a back-end coder so I slap together a usable
interface with crude html (the only kind I know), then let a real web
designer handle making it look nice (that person doesn't have to be a
programmer). It's relatively easier to get someone like that involved
in a project than someone who can do good visual stuff AND write code,
as is (to some extent) needed for a client side GUI.

But I'd really like to try something different.

A year-long mission critical project is not the time or place to try
something different. Better start with something easier.

Some reasons for them would be (in no particular order): 1) More
responsive and user-friendly interfaces, 2) Much better ability to
sort, export, import, and print data (very important), 3) Easier to
"lock down" who's using the program by only installing it on certain machines.

1) is true in principle and but a heck of a lot of apps don't really
use the capability. There's tons of crappy gui apps out there that
could be done just as well with no client installation.

2) I don't understand this part. Sort = server side.
Export/import/printing: upload and download files? Depending on your
requirements a little bit of browser scripting may be enough to handle
this. 3) I don't agree with this at all, and if you were trying to
pitch your project to me I'd be asking you a lot of questions about
security, in particular whether you're up to integrating SSL into both
your server and client, as well as they're already integrated into
existing browsers and http servers, which were written by experts and
have had tons of review and testing, yet problems still occasionally
turn up with them. (Hmm, maybe you could use something like stunnel,
yet another client install.) Since you're handling personal and
financial info maybe you should be using multi-factor authentication
(hardware tokens with client certificates) and browsers already handle
the client side of that (Windows CAPI in Explorer or PKCS#11 plugin
for Firefox).

usability of a desktop app is rather frightening. I've done plenty of
stuff with AJAX, and it certainly has its purpose, but it gets
incredibly bloated and fragile *very* quickly.

Yes I agree with this. There are multiple judgement calls as to 1)
when the maintenance tradeoff starts tilting towards a thick client vs
AJAX when you need certain interface features that can be done either
way; and 2) whether you REALLY need those features. Again, if you
were trying to pitch this project to me, I'd want to see some sample
screen designs with a persuasive argument that their functions
couldn't be done as effectively in html, if necessary using a small
java applet or embedded browser plug-in to handle stuff like file i/o
or whatever.

My manager even wants use cases (if you've never had to deal with
use cases, consider yourself a lucky, lucky person) which I am going
to attempt to argue as that is even going *too* far.

You definitely need use cases. You should also put together some
sample screens to figure out the user interactions. You won't be
surprised to hear that I usually do those in html.

So, long story short (too late), no Extreme Programming for me.

I'm not a real adherent of Extreme Programming (abbreviated XP, not to
be confused with Windows XP) like some folks on this newsgroup are,
but some of its ideas are worth studying. In particular, doing
bite-sized incremental development with very frequent interaction with
the customer, letting them try out new code as the implementation
progresses, can save you from surprises.

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :
(snip)

We have found the object-relationship managers

Actually, ORM stands for "object-relational mapper"

to be bloated
and unruly.

Which ones ?

 

[vanrpeterson]

We totally agree with your software engineering goals. Relying on
wxPython and minimizing web reliance brings sanity to the enterprise.
We too love PostgreSQL and avoid XML whether cleaned by SOAP at all
costs. We have found the object-relationship managers to be bloated
and unruly. What are you building and how many hours per month are
you willing to spend supporting it?

 

[vanrpeterson]

We totally agree with your software engineering goals. Relying on
wxPython and minimizing web reliance brings sanity to the enterprise.
We too love PostgreSQL and avoid XML whether cleaned by SOAP at all
costs. We have found the object-relationship managers to be bloated
and unruly. What are you building and how many hours per month are
you willing to spend supporting it?

 

[Jeff]

Wow, there's a lot to respond to here. Thanks everyone for your
help. I'll try to go in order.

askel: Thanks, I've looked at this a little bit before, but now I've
looked into it a little further. Seems pretty cool, but also fairly
complex. Have you used it before?

David: Sounds like a pretty interesting app. Thanks for the in-depth
description. I went and checked out Twisted PB, and it seems
awesome. I may very well go with that. How was writing code with
it? I may also end up using py2app, but I'm also going to have to
support Windows, (p2exe, then), and possibly Linux. Well, maybe not
Linux, but I'll probably be doing most of the development in Linux, so
I guess that counts.

Paul: Again, I appreciate all of your input. Responses below--

It's relatively easier to get someone like that involved
in a project than someone who can do good visual stuff AND write code,
as is (to some extent) needed for a client side GUI.

Well, it's going to be just me (maybe some part-time help, but nothing
I can rely on), so either way, I'm writing the whole thing.

1) is true in principle and but a heck of a lot of apps don't really
use the capability. There's tons of crappy gui apps out there that
could be done just as well with no client installation.

Granted. But what I will be writing really will take a lot of extra
work to get even close to the level of usability needed on the web vs.
a desktop app. And I'll try not to write a crappy GUI ;-)

2) I don't understand this part. Sort = server side.
Export/import/printing: upload and download files? Depending on your
requirements a little bit of browser scripting may be enough to handle
this.

Sorting certainly doesn't have to be done on the server side--in fact,
in most cases I can think of where it would be useful for this app, it
wouldn't have to be--in which case it's more responsive. Certainly
exporting, importing and printing can all be done through the web--
I've done this plenty of times. But there is a huge amount of
flexibility (and, in the case of printing, guaranteed style/quality/
layout) to be gained on the desktop.

For #3, see my previous response to Bruno. It was a poor choice of
wording on my part.

As for the AJAX--I'm going to need to use it *a lot* for the sake of
my clients. They're used to (and very much want) usable interfaces
that really can't be made without it. And even if I use it liberally,
it still won't be anywhere as usable as a desktop application.

All that said, I am most likely going to go with a desktop
application. In reality, I will have to do whatever my client wants.
Thank you *very* much for all of your input--one of the first things I
have to do is make them a list of the pros and cons of web vs. desktop
apps--and this will help a lot.

vanrpeter-whatever: Thanks for the support What did you use for
networking? What ORMs did you try (or did you skip them altogether?)
As for what I'm building--it's a personnel tracking/payroll system--
see my first post for a fuller description. Hours will be... well, a
lot. Our current contract is for 4 days a week for a year, but that's
for development--I'm not sure how much of a support contract they'll
want afterwards, or if they'll want further development (probably).

Once again, thanks everyone!

 

[David Bolen]

David: Sounds like a pretty interesting app. Thanks for the in-depth
description. I went and checked out Twisted PB, and it seems
awesome. I may very well go with that. How was writing code with
it? I may also end up using py2app, but I'm also going to have to
support Windows, (p2exe, then), and possibly Linux. Well, maybe not
Linux, but I'll probably be doing most of the development in Linux, so
I guess that counts.

I find PB very easy, but it's important to first become familiar with
Twisted (in particular Deferred's), which can have a steep, but worth
it IMO, learning curve. PB is a thin, transparent system, so it
doesn't try to hide the fact that you are working remotely. Being
thin, there also isn't very much to have to learn.

For packaging, you don't have to use a single system if you are
multi-platform. Your codebase can be common, and just have separate
setup files using py2app on OS X and py2exe on Windows. A makefile or
equivalent can handle final distribution packaging (e.g,. hdiutil for
dmg on OS X, Inno Setup, NSIS, etc... on Windows). You'll spend some
platform-specific time getting the initial stuff setup, but then new
builds should be easy.

For Linux, depending on the level of your users you can either just
directly ship something like eggs (generated through a setup) or look
into pyInstaller, which was the old Installer package that also
supports single-exe generation for Linux. pyInstaller also does
Windows, so if you have to support them both you could try using
pyInstaller rather than both it and py2exe.

But if you're just developing in Linux, final packaging probably isn't
very important.

-- David

 

[Paul Rubin]

Granted. But what I will be writing really will take a lot of extra
work to get even close to the level of usability needed on the web vs.
a desktop app. And I'll try not to write a crappy GUI ;-)

OK. In the discussion with Chris, one factor that came up is how much
time users will spend in front of the app and the amount of data
they'll physically enter. If it's a lot, that weighs in favor of a
desktop app. If it's not much, then maybe some gain in UI
responsiveness isn't worth the downside of a client installation.

Sorting certainly doesn't have to be done on the server side--in fact,
in most cases I can think of where it would be useful for this app, it
wouldn't have to be--in which case it's more responsive. Certainly
exporting, importing and printing can all be done through the web--
I've done this plenty of times. But there is a huge amount of
flexibility (and, in the case of printing, guaranteed style/quality/
layout) to be gained on the desktop.

This I don't understand at all. How is the least bit of flexibility
or style or quality guarantees gained by a desktop app? If you want
fancy formatting, just use Reportlab to generate a pdf on the server
and send it to the browser.

All that said, I am most likely going to go with a desktop
application. In reality, I will have to do whatever my client wants.
Thank you *very* much for all of your input--one of the first things I
have to do is make them a list of the pros and cons of web vs. desktop
apps--and this will help a lot.

Yes, that sounds like a good idea.

vanrpeter-whatever: Thanks for the support What did you use for
networking? What ORMs did you try (or did you skip them altogether?)

Have you ever written a serious GUI app before? I've never done any
really fancy ones, but even the relatively simple ones I've done have
turned out to be far more time consuming than I expected. Have you
done much concurrent programming, either with threads or something
like twisted? You're going to have to do that to keep your gui
responsive, so you might put that on your list of things to study (in
addition to networking and databases).

 

[Kathryn Van Stone]

Greetings,

I somehow missed some of this thread, but I believe you left a note
saying that you were not able to do Extreme Programming.

However, based on the description of the size of the project and the
size of the development team (is there any more than you?) I would
recommend you consider the following agile techniques:

1. Incremental development
2. Automated testing
3. Continuous integration

I think 1 and 3 are important in giving you a continuously working
system, along with a working system you can use for feedback during
the development process. Automated testing would support 1 and 3 and
keep you from having to do a lot of manual testing. Wikipedia
describes most of those terms.

Also think about having acceptance tests that someone besides you can
verify match the specifications.

Lastly do use the fact that you are (presumably) close to some of
your customers to use face time for additional communication usually
needed beyond specs.

I hope this helps. It sounds like a useful project.

Kathy Van Stone
(e-mail address removed)