Creating a multi-tier client/server application

[Bruno Desthuilliers]

Paul Rubin a écrit :
> Jeff <jeff.fw at gmail.com> writes:
>> 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.
> 
(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).

>> 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.

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...