In article <[EMAIL PROTECTED]>, Bob Greschke <[EMAIL PROTECTED]> wrote: > >"Paul Rubin" <http://[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> "Bob Greschke" <[EMAIL PROTECTED]> writes: >>> What I came up with was the user can just create a text file (a kind >>> of a transaction log of what things were done to the copy of the >>> database on his machine), then cut and paste that text into a window >>> created on their machine by the main database program (using >>> X-windows, ssh, etc.), then the main program can read the contents >>> of that text field and update the main copy of the database. >>> >>> It should work. :) >> >> Yuck! Why not use an http interface instead of the remote tkinter >> interface? Then the user would interact with your app through a web >> browser, giving a familiar UI as well as giving that upload button >> (which tells the browser to upload the file). > >Mainly because the user may be in the middle of the Himalayas trying to >create paperwork for equipment being shipped to Japan and Chile. The >Internet is not always an option in our line of work. We need to have >standalone everythings. We don't live in your real world. :) > >The two databases (the one on the user's laptop, and the one back at the >office) don't need to be reconciled until the user gets back. We just need >to (eventually) know which pieces of equipment were sent to Japan, and which >went to Chile. . . . Certainly. And, if you're content with what you have, that's great; *I* certainly do enough funny things with Tkinter and X. But what you *can* do is deploy the end-user desktop with a browser pointed to a local Web page, presumably one with enough client-side processing to prepare a form. Then, when he's within range of an IP address, he selects an "upload" link, and you get all the HTTP-related advantages Paul and others have mentioned. -- http://mail.python.org/mailman/listinfo/python-list
