Creating a multi-tier client/server application

[Paul Rubin]

Jeff <jeff.fw at gmail.com> writes:
> 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.