I fully agree with you. This would be an external tool. But I underlined that building such a tool is not a big enterprise. It can be done by a good programmer in a reasonable amount of time.
Also, I would say that perfect sync over network file systems done by sqlite is out of sqlite's scope. Especially if this would involve custom sync mechanisms designed for each file system. -----Original Message----- From: Jay Sprenkle [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 08, 2006 8:18 AM To: [email protected] Subject: Re: [sqlite] File locking additions On 3/7/06, Marian Olteanu <[EMAIL PROTECTED]> wrote: > I would say that the best way to access a sqlite database mounted from a > remote file server, concurrently with other processes is through a database > server. My opinion is that the overhead of file sync and file locking for a > remote file system is higher than simple TCP/IP communication overhead. The > server would be able to use also the same cache, would have very fast access > to the file (local file), etc. > > Building a server for sqlite is not a very complicated task. It can take as > few as a couple hours. I'd like to see this option built as a separate project from sqlite. Sqlite is a great tool when you don't need a server, and I'd hate to lose that. Let's add more tools to our toolset instead of just morphing one into whatever is needed at the moment.
