Reading the paper
http://www.tcl.tk/community/tcl2004/Papers/D.RichardHipp/drh.html
- especially the paragraph "SQLite Extensions Written In Tcl" - I was
wondering, if could be possible to arrange something like this:

Suppose, we have one SQLite database with several connections from different
clients; a shared database. Knowing about SQLite's close relations to Tcl
I'm wondering: could be possible to write some kind of trigger or extension
in Tcl (or anything like this), which could be used to change the contents of
variable, which will be "shared" by all the currently connected Tcl
applications, utilizing the database?

By "shared variable" I mean, that its contents can be changed by any of the
users, and it can be "seen" without any polling (no "selects" neither any
other SQL commands periodically executed to "refresh"); it should be seen
just like any other variable in Tcl application, to - for example - set a
"trace" (Tcl's "trace", of course) on such variable, allowing to trigger
some kind of action.

Of course, the above is just idea, not the exact expectation; one can think
about some kind of trigger, which will change some variables seen by every
connected client individually (but of the same name for every client) - and
in the end the result will be about the same. But two conditions should be
fullfilled (if possible):

- It shouldn't need any special setup from client's side (or very minimal?).
  I would just have, let's say, a variable $messageFromSQLite available in
  the app's global namespace, immediately after successful connection to
  a database. A variable, which can be then "traced".

- Any change to that variable's contents should be reflected in the
  "corresponding" variables of the other clients. That's why I'm writing
  about "sharing" - and I don't want any "polling". The "polling" is just
  obvious: sharing a database (doing "SELECT" and so on) is "polling"
  anyway, right? And I'm wondering, if database could be "active" side, not
  just "waiting for query".

Could be something like this possible at all?
-- 
                                pozdrawiam / regards

                                                Zbigniew Baniewski

-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to