[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list