Quoting [EMAIL PROTECTED]: > > > > > Agree in principle with what you're saying here as well, one suggestion > > - perhaps you could mod your server to accept/general queries/output via > > standard in/out. That way its could be piped over a multitude of channels. > > > > Cheers - Lindsay > > The architecture would be all wrong for doing that. It would be easy to > make a very little program which passes queries on stdin to the > sqlite3_exec routine and then use the callback function from uSQLite to > reply in the same format. > > Thing is, you only have one standard in and out, it could only do 1 > client. > You can just use the traditional Unix method - accept a connection on STDIN then duplicate the file descriptor and fork the process to create a new thread of execution. You can also do it in one process by creating a thread for each user context. SQLITE already maintains locks so there is no special logic required to synchronize concurrent access to a Sqlite database.
I also note from this discussion that HTTP is misunderstood. It is merely a very simple, lightweight, connectionless communications protocol which is universally used. An HTTP server or client can be implemented in a few lines of Perl or from the ground up (socket API level) in a few hundred lines of C. It can be used as a transport protocol layer in a well designed product. When implemented that way it can be replaced by a more appropriate protocol for a particular application, for example when the overhead of the text based, connectionless HTTP is not warranted on a lightweight embedded system which does not have to penetrate firewalls. JS ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
