Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Creating a multi-tier client/server application

Reply
Thread Tools

Creating a multi-tier client/server application

 
 
askel
Guest
Posts: n/a
 
      08-29-2007
On Aug 29, 1:31 pm, Jeff <(E-Mail Removed)> wrote:
> Goldfish--thanks, I'll check it out.
>
> > > 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.

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

 
Reply With Quote
 
 
 
 
David Bolen
Guest
Posts: n/a
 
      08-29-2007
Jeff <(E-Mail Removed)> writes:

> 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
 
Reply With Quote
 
 
 
 
Paul Rubin
Guest
Posts: n/a
 
      08-30-2007
Jeff <(E-Mail Removed)> 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.
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      08-30-2007
http://www.velocityreviews.com/forums/(E-Mail 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 ?
 
Reply With Quote
 
vanrpeterson@gmail.com
Guest
Posts: n/a
 
      08-30-2007
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?

 
Reply With Quote
 
vanrpeterson@gmail.com
Guest
Posts: n/a
 
      08-30-2007
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?

 
Reply With Quote
 
Jeff
Guest
Posts: n/a
 
      08-30-2007
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) More responsive and user-friendly interfaces

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

 
Reply With Quote
 
David Bolen
Guest
Posts: n/a
 
      08-30-2007
Jeff <(E-Mail Removed)> writes:

> 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
 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      08-31-2007
Jeff <(E-Mail Removed)> writes:
> 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).
 
Reply With Quote
 
Kathryn Van Stone
Guest
Posts: n/a
 
      09-04-2007
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 Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"Error Creating Control" when creating a custom control (Design Time). Can't see tooltip message. Ravi Ambros Wallau ASP .Net Web Controls 0 06-01-2005 02:36 PM
"Error Creating Control" when creating a custom control (Design Time). Can't see tooltip message. Ravi Ambros Wallau ASP .Net 0 06-01-2005 02:36 PM
Creating an ASP.NET application on XP Pro =?Utf-8?B?UmFuZHk=?= ASP .Net 3 01-24-2004 01:55 AM
Creating Domino.NotesSession from APS.NET application Rodney ASP .Net 0 09-08-2003 09:30 AM
Need help on creating a shortcut to a Web Application using a .NET Web Setup project in VS.NET 2003. Chetna Joshi ASP .Net 0 07-05-2003 01:50 PM



Advertisments