Creating a multi-tier client/server application

Discussion in 'Python' started by Jeff, Aug 29, 2007.

  1. Jeff

    Jeff Guest

    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
     
    Jeff, Aug 29, 2007
    #1
    1. Advertising

  2. Jeff

    Paul Rubin Guest

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

    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.
     
    Paul Rubin, Aug 29, 2007
    #2
    1. Advertising

  3. Paul Rubin a écrit :
    > Jeff <> 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...
     
    Bruno Desthuilliers, Aug 29, 2007
    #3
  4. Jeff

    Jeff Guest

    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.
     
    Jeff, Aug 29, 2007
    #4
  5. Jeff a écrit :
    > 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)


    Why so ???

    > to
    > program the client-side app.
     
    Bruno Desthuilliers, Aug 29, 2007
    #5
  6. 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.
     
    Bruno Desthuilliers, Aug 29, 2007
    #6
  7. Jeff

    Jeff Guest

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


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

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


    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!
     
    Jeff, Aug 29, 2007
    #7
  8. Jeff

    Goldfish Guest

    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!
     
    Goldfish, Aug 29, 2007
    #8
  9. Jeff a écrit :
    >> 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,


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

    (snip)
     
    Bruno Desthuilliers, Aug 29, 2007
    #9
  10. Jeff

    Jeff Guest

    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.
     
    Jeff, Aug 29, 2007
    #10
  11. Jeff

    askel Guest

    On Aug 29, 1:31 pm, Jeff <> 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/).
     
    askel, Aug 29, 2007
    #11
  12. Jeff

    David Bolen Guest

    Jeff <> 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
     
    David Bolen, Aug 29, 2007
    #12
  13. Jeff

    Paul Rubin Guest

    Jeff <> 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.
     
    Paul Rubin, Aug 30, 2007
    #13
  14. a écrit :
    (snip)
    > We have found the object-relationship managers


    Actually, ORM stands for "object-relational mapper"

    > to be bloated
    > and unruly.


    Which ones ?
     
    Bruno Desthuilliers, Aug 30, 2007
    #14
  15. Jeff

    Guest

    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?
     
    , Aug 30, 2007
    #15
  16. Jeff

    Guest

    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?
     
    , Aug 30, 2007
    #16
  17. Jeff

    Jeff Guest

    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!
     
    Jeff, Aug 30, 2007
    #17
  18. Jeff

    David Bolen Guest

    Jeff <> 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
     
    David Bolen, Aug 30, 2007
    #18
  19. Jeff

    Paul Rubin Guest

    Jeff <> 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).
     
    Paul Rubin, Aug 31, 2007
    #19
  20. 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
     
    Kathryn Van Stone, Sep 5, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. rob

    ASP v2 & 3-tier or 2-tier

    rob, Aug 13, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    414
    Steve C. Orr [MVP, MCSD]
    Aug 13, 2004
  2. NOSPAM

    2 tier to 3 tier?

    NOSPAM, Oct 14, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    435
    =?Utf-8?B?Q293Ym95IChHcmVnb3J5IEEuIEJlYW1lcikgLSBN
    Oct 14, 2004
  3. Shantanu Bhattacharya
    Replies:
    2
    Views:
    558
    Christopher Benson-Manica
    Dec 26, 2003
  4. Shantanu Bhattacharya

    Converting a 2-tier application to 3-tier application

    Shantanu Bhattacharya, Dec 25, 2003, in forum: C Programming
    Replies:
    2
    Views:
    463
    Christopher Benson-Manica
    Dec 26, 2003
  5. Ross

    Creating IIS Login to SQL Server in multi-tier app

    Ross, Nov 6, 2004, in forum: ASP .Net Web Services
    Replies:
    1
    Views:
    143
    Dino Chiesa [Microsoft]
    Nov 8, 2004
Loading...

Share This Page