Cookies

[Steve Holden]

Outlook Express. Aarrgghh. I have *no* idea why it isn't mail-quoting this
content, and can't be bothered messing with settings any more.

Sorry ...

"Ken Seehof" <kens at sightreader.com> wrote in message
news:mailman.985050745.11337.python-list at python.org...
Thanks for your help and persistence.  I have come to an adequate
compromise solution. . . .

"David Bolen" <db3l at fitlinxx.com> writes:
> "Ken Seehof" <kens at sightreader.com> writes:
>
> > > Or, if it isn't going to connect to the server, how about just letting
> > > the Python application open up it's own web page internally to run
> > > appropriate code on your web server to generate the identifier (which
> > > could run as a server script), and then Python could parse it right
> > > from the resulting HTML information.
> >
> > Again, it's the same catch-22.  I need the server to generate the same
> > id that the javascipt generated earlier, but I need each client to have
> > a unique id.
>
> I'm still somewhat confused as to the requirement that your javascript
> needs the identifier - is there something else it gets used for as
> part of the web page other than to generate it on behalf of the
> application?

Yes, the page where the user downloads the application also contains
a form (to be filled out while the user is waiting for the download).
The data in the form is written to a database on the server keyed by
the newly generated identifier.  When the application is downloaded,
it uses the same identifier to query the server database for the form
data.  Of course since there are multiple clients, the server needs to
know which client is making the request.

[SH] Erm, is the download still valid if the user fails to submit the form?
This sounds a bit like yer classical modal operation (but I'm guessing).
Might the response rate increase if they had to fill the form out before
they got the download? In which case, might the response to the form be
available tp condition the download process? (Guessing again).


The solution I've ended up with is for the server to generate the id,
the web page to display it, and the application to prompt the user to
manually type it in.

[SH] They had better really *want* this software ...

It would be nice to skip the step where the application prompts the
user (hence the search for a cookie oriented solution), but now that
I see it in action it's not really a big deal (i.e. problem solved, unless
there's a really clever idea that doesn't involve any other compromise).

> If you support generating the id the first time via a script running
> from a normal browser, couldn't you do the same thing as I suggested
> above by letting your application itself be that browser - you could
> just generate the id server side and parse the results right within
> your application, so no need to transfer the id at all.
>
> In other words, why not just use the web page to download the app, and
> that's it.  Don't depend on the web page and browser access for
> anything else.  Let your application connect to your server (since you
> mention it'll do it anyway) and during its first execution get the
> server to generate the id and then use it from there.

I want the browser to be the user interface for the form because the
the application must be very lightweight (i.e. not be a GUI).  There are
other reasons as well to do it this way.  The executable comes from a
possibly overburdened central server, but the data entry form (which
may be customized) is on any of several custom servers (which don't
have enough security to offer an executable).

[SH] Reminder: web clients need to have GUI's: anything you can do sitting
at your browser, a Python web client program can do too (well, not look at
the pages, but I'm sure you understand what I mean).

> If you need to have the first generation take place in the context of
> an HTTP session, that can still be encapsulated by your Python
> application rather than depending on a separate Javascript execution
> in a different browser.

Thanks again everyone,
- Ken

hoping-i'm-not-flogging-this-to-death-ly y'rs  - steve