Hello, First off, agreed an ODBC interface would be more suitable and secure, don't trust today-most-web-devs to make the RPC layer secure [cruft-obfuscation open backdoor they know], not trolling around just the day to day reality; when I sit on some server-codes ... if you can call that "code" at all.
Second off, concurrent writings/readings to a sqlite's db-file is a bit odd, challenging 40 years of evolution, e.g there are a lot of stuff you don't need at runtime, then do you extract a suitable "workable runtime image" or you just use the provided plain-sqlite-interface ? Best. On Fri, Apr 18, 2014 at 7:23 AM, Dennis Jenkins <dennis.jenkins...@gmail.com > wrote: > On Fri, Apr 18, 2014 at 6:32 AM, Christian Smith < > csm...@thewrongchristian.org.uk> wrote: > > > On Tue, Apr 01, 2014 at 01:08:59PM +0000, Harmen de Jong - CoachR Group > > B.V. wrote: > > > We have built our own SQLite database server application and are > > considering making this open source. Since there will be some time > involved > > into making it an open source project and maintaining it, we would first > > like to make an inventory to find out if there is any interest in this > > server application. > > > > > > ==> How it works: > > > > > > Clients can communicate with this server over TCP/IP sockets. Queries > > are submitted and returned in XML format (BLOB results are returned in > > binary format to prevent CPU intensive encoding and decoding). The server > > application is written in native Visual C++ (without using MFC). If we > > would make this project open source we would also include a client > example. > > > > > > I dare say that parsing and encoding XML would be more processor > intensive > > that BLOB encoding. > > > > IMO, you'd also increase your potential target audience if you could also > > provide reasonably functional JDBC, ADO.NET, PHP and/or Python database > > drivers. Providing any of these would allow existing users to plug your > new > > database into existing applications with the minimal of fuss. > Personally, I > > don't like the idea of XML as the protocol, largely because of the > parsing > > overhead, and have been looking at a similar server based on RPC, but for > > debugging purposes it would be great. > > > > Regards, > > Christian > > _______________________________________________ > > > > > Not all XML libraries are inefficient. TinyXml2 would probably work great > for this use-case. (disclaimer: I use TinyXml2 in an unrelated project, > but I am not the author). > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users