Application architecture (long post - sorry)

[Mike Meyer]

limeydrink at hotmail.com writes:
> I have looked at the options for developing the client for these
> "electronic job sheets" and have decided upon Microsoft Pocket PC and
> the .net compact framework.  It seems the easiest environment for
> developing and the PDA's can be obtained very cheaply as a package from
> a GSM/GPRS data carrier.

That seems like overkill for this application.

> Problem 1 - Physical connectivity
> how would I make the actual network connection in to the server from
> the client
> Running a VPN connection over GPRS ?
> Connecting to the web on the client then using web services ?

The physical connectivity isn't your worry. How you access it from
software depends on your chosen platform.

> The above decisions probably depend on the answer to problem 2...
> How to connect to the data
> Or even simpler I could just export data for the engineers into XML or
> .csv files and expose them using a web server the client then just
> connects to the server and then downloads the job data , and uploads
> completed job information

I've gone this route before, and this is why I say your .net solution
looks like overkill. The phones that GSM providers *give away* have
web browsers built into them, and it's been that way for years. No
need for .net or Pocket PC or whatever on the mobile device - just get
a web-enabled phone. This makes half the development trivial - you
don't have to do *any* development on the mobile side of things.

The hard part for you will be finding a competent web designer who
understands the web well enough to write for something other than
WinIE - in particular, who can produce pages that will work properly
on your target platform, no matter what it is.

The second hardest part will be picking the mobile platform. That will
depend on what you want to display, as low-end devices any not have a
big enough display, and on what kind of data entry has to be done in
the field: if cursor motion and select is enough, any thing will do. A
phone keypad is ok for short text. For longer things, you may want
something like Graffiti or even a real keypad. This latter takes you
out of phones and back into Pocket PC land - but only to get the UI,
not for development.

Once you've chosen the platform, you'll know what browser it has
available, and that will provide the requirements for the web
developer. The range is from simple (no frames, limited table nesting,
no CSS, no JS, and similar things) to very complete (Opera runs on
some of these devices.  They call the Pocket PC browser IE, but I've
never dealt with it).  You can design web apps to work around any/all
of these things being missing; all it takes is that competent web
designer.

I normally recommend picking the software first, and lettinng that
drive the choice of hardware. But in this case, the hardware is a
crucial part of the user interface, and you need to make sure that
that's acceptable. And the mobile hardware choice - assuming you go
the web route - isn't going to have a critical effect on the server
software.

> Or (this is where the bulk of the python part comes into it), I create
> a network server in Python that the clients connect to this could be a
> two way thing then, as the client app could connect first thing in the
> morning and collect jobs but I could also push data to the client such
> as job updates and notifications making it much smarter and
> interactive.

Web servers generally don't do push. There are technologies that do -
but then you're limiting your mobile platform choices to things that
support it, or having to port it yourself. Unless there's a real
reason for wanting to push the data, I'd avoid it. That doesn't mean
the your field engineers can't get updates whenever they want - they
just have to ask for them.

There are lots of python choices for building web applications. Maybe
to many. You could use just about any of them.

> There are currently around 60 engineers and they will be requesting
> data at specific times, first thing in morning and probably midday
> being the most busy times where probably all engineers will be
> connecting at once.

You'll need to make sure you have a fast enough machine for that. A
33MHz 386 ought to do the trick :-).

> So if I go down the network server route it will have to handle
> multiple connections from clients and then connect to a database to
> retrieve job information for each specific engineer and then send over
> the connection to the client.

This is a pretty standard architecture for a web application. Any of
the python web application tools can handle this.

    <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.