> This sounds like a great thing. I presume that your -code option will be
> implemented by posting an event. If so, it will be relatively easy to
> integrate into the single-threaded tclhttpd. All that will happen is
that
> the script passed to -command will need is to call Httpd_ReturnData or
> Httpd_ReturnFile (and of course, it will need the correct arguments to
allow
> it to give these routines everything they need).
My original thinking was that the -code "xxx" was evaled by the completed
routine.
Another thought we had was to make SQL work with fileevent, so that it is
readable when the query results come back, and writeable once the currently
pending query is finished. On a certain level, a SQL connection really is
a TCP/IP connection (behind the nasty Oracle API), so it does behave like
an io device.
However, I haven't looked at how fileevent works to see how we'd hook our
C++ stuff on top of it.
Otherwise, a generic event would certainly work.
> I would also ask if your use of --command was a typo. If not, then it
> appears that you are using a double dash for options. This is very much
not
> in keeping with traditional TCL style and would prevent your package from
> being picked up by scriptics. Can you comment on this?
Brain lapse, sorry. Yes, we're using -option xx as it is used elsewhere in
Tcl.
|--------+------------------------------>
| | Ted Dunning |
| | <tdunning@musicmatch|
| | .com> |
| | |
| | 07/24/00 09:54 AM |
| | |
|--------+------------------------------>
>--------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: "'John Buckman'" <[EMAIL PROTECTED]>
|
| cc: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]> |
| Subject: RE: async page rendering for SQL ?
|
>--------------------------------------------------------------------------------------------------------------------------------------|
This sounds like a great thing. I presume that your -code option will be
implemented by posting an event. If so, it will be relatively easy to
integrate into the single-threaded tclhttpd. All that will happen is that
the script passed to -command will need is to call Httpd_ReturnData or
Httpd_ReturnFile (and of course, it will need the correct arguments to
allow
it to give these routines everything they need).
I would also ask if your use of --command was a typo. If not, then it
appears that you are using a double dash for options. This is very much
not
in keeping with traditional TCL style and would prevent your package from
being picked up by scriptics. Can you comment on this?
-----Original Message-----
From: John Buckman [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 24, 2000 9:18 AM
To: [EMAIL PROTECTED]
Subject: async page rendering for SQL ?
We're completing our own Tcl-to-SQL library, and have the opportunity of
implementing the SQL library with async-calls.
So, for example, a SQL select query would have some --code "..." associated
with it, that runs once the SQL select query completes
The reason I bring this up here, is that instead of using multithreading
inside TclHttpd, we'd prefer to use the single-threaded version of
TclHttpd, and pages that render asynchronously, when the operation
completes. I have some ideas on how I could hack TclHttpd to do this, but
I'm wondering (Brent?) if there could be a standard mechanism for doing
this. Perhaps one could register a page as "unfinished" and then call a
"finisher" proc once the page was available.
--
About our TclDBTools library:
We're using Rogue Wave's DBTools library (a commercial C++ library
(www.roguewave.com), and it will support Oracle, ODBC, Microsoft-SQL,
Sybase, DB2 & Informix, all native, on both Unix and Windows. We're going
to make the library open-source and available to all, in a few weeks.
