<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.3105.105" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>Thanks for your help and persistence. I have come to an
adequate<BR>compromise solution. . . .<BR><BR>"David Bolen" <<A
href="mailto:db3l@fitlinxx.com">db3l@fitlinxx.com</A>> writes:<BR>> "Ken
Seehof" <<A href="mailto:kens@sightreader.com">kens@sightreader.com</A>>
writes:<BR>><BR>> > > Or, if it isn't going to connect to the
server, how about just letting<BR>> > > the Python application open up
it's own web page internally to run<BR>> > > appropriate code on your
web server to generate the identifier (which<BR>> > > could run as a
server script), and then Python could parse it right<BR>> > > from the
resulting HTML information.<BR>> ><BR>> > Again, it's the same
catch-22. I need the server to generate the same<BR>> > id that the
javascipt generated earlier, but I need each client to have<BR>> > a
unique id.<BR>><BR>> I'm still somewhat confused as to the requirement
that your javascript<BR>> needs the identifier - is there something else it
gets used for as<BR>> part of the web page other than to generate it on
behalf of the<BR>> application?<BR><BR>Yes, the page where the user downloads
the application also contains<BR>a form (to be filled out while the user is
waiting for the download).<BR>The data in the form is written to a database on
the server keyed by<BR>the newly generated identifier. When the
application is downloaded,<BR>it uses the same identifier to query the server
database for the form<BR>data. Of course since there are multiple clients,
the server needs to<BR>know which client is making the request.<BR><BR>The
solution I've ended up with is for the server to generate the id,<BR>the web
page to display it, and the application to prompt the user to<BR>manually type
it in.<BR><BR>It would be nice to skip the step where the application prompts
the<BR>user (hence the search for a cookie oriented solution), but now that<BR>I
see it in action it's not really a big deal (i.e. problem solved,
unless<BR>there's a really clever idea that doesn't involve any other
compromise).<BR><BR>> If you support generating the id the first time via a
script running<BR>> from a normal browser, couldn't you do the same thing as
I suggested<BR>> above by letting your application itself be that browser -
you could<BR>> just generate the id server side and parse the results right
within<BR>> your application, so no need to transfer the id at
all.<BR>><BR>> In other words, why not just use the web page to download
the app, and<BR>> that's it. Don't depend on the web page and browser
access for<BR>> anything else. Let your application connect to your
server (since you<BR>> mention it'll do it anyway) and during its first
execution get the<BR>> server to generate the id and then use it from
there.<BR><BR>I want the browser to be the user interface for the form because
the<BR>the application must be very lightweight (i.e. not be a GUI). There
are<BR>other reasons as well to do it this way. The executable comes from
a<BR>possibly overburdened central server, but the data entry form (which<BR>may
be customized) is on any of several custom servers (which don't<BR>have enough
security to offer an executable).<BR><BR>> If you need to have the first
generation take place in the context of<BR>> an HTTP session, that can still
be encapsulated by your Python<BR>> application rather than depending on a
separate Javascript execution<BR>> in a different browser.<BR><BR>Thanks
again everyone,<BR>- Ken<BR><BR><BR></DIV></BODY></HTML>