On Tue, Aug 31, 2010 at 19:51, Richard Hipp d...@sqlite.org wrote:
My suggestion is that you make a copy of the os_unix.c source file (call it
chromium_vfs.c or anything else that you like) and apply your edits to that
copy.
FYI, that's what finally happened.
On Tue, Aug 31, 2010 at 10:51, Richard Hipp d...@sqlite.org wrote:
My suggestion is that you make a copy of the os_unix.c source file (call it
chromium_vfs.c or anything else that you like) and apply your edits to that
copy. Since you started with an exact copy of the original os_unix.c
On Wed, Sep 1, 2010 at 5:57 PM, Paweł Hajdan, Jr.
phajdan...@chromium.org wrote:
Additionally, browsers seem to be moving to the multi-process architecture
(Chrome, Firefox, WebKit2), so I wouldn't be surprised if you get more
questions about this in the future, or just more forked copies.
2010/8/31 Richard Hipp d...@sqlite.org
os_unix.c is very unlikely to change in ways that you care about.
I think the biggest concern is just copying that code, please see
http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/7f8e9bf0f034322f/b26e422d4aa711c7.
I think
What do you think about extending the SQLite VFS to make it possible
to open
a database having a file handle (fd on Unix, HANDLE on Windows)?
Opening
based on file path would still be there (to preserve compatibility).
How do you know which journal file to open or where to create
a
I wonder whether it would be possible to extend the VFS in a way that would
make our use case possible (transferring a file handle over process
boundary). Please note that we do it on all platforms. On POSIX we pass an
integer file descriptor, and on Windows we pass a HANDLE.
I used vfs for
On Wed, Sep 1, 2010 at 10:20 PM, Max Vlasov max.vla...@gmail.com wrote:
I wonder whether it would be possible to extend the VFS in a way that would
make our use case possible (transferring a file handle over process
boundary). Please note that we do it on all platforms. On POSIX we pass an
On Fri, Aug 27, 2010 at 18:27, Paweł Hajdan, Jr. phajdan...@chromium.orgwrote:
At start-time, simply call sqlite3_vfs_register() to register your
customized VFS with SQLite.
That's what our implementation effectively does, see
And we can't have the entire implementation on the
WebKit/Chrome side either, because then we can't compile against vanilla
SQLite (and Linux distributions don't like it).
Could you explain in detail where this can't comes from and what's
the problem with Richard's suggestion to copy necessary
On Tue, Aug 31, 2010 at 1:19 PM, Paweł Hajdan, Jr.
phajdan...@chromium.orgwrote:
On Fri, Aug 27, 2010 at 18:27, Paweł Hajdan, Jr. phajdan...@chromium.org
wrote:
At start-time, simply call sqlite3_vfs_register() to register your
customized VFS with SQLite.
That's what our
On Tue, Aug 31, 2010 at 10:51, Richard Hipp d...@sqlite.org wrote:
My suggestion is that you make a copy of the os_unix.c source file (call it
chromium_vfs.c or anything else that you like) and apply your edits to that
copy. Since you started with an exact copy of the original os_unix.c
On Tue, Aug 31, 2010 at 1:56 PM, Paweł Hajdan, Jr.
phajdan...@chromium.orgwrote:
On Tue, Aug 31, 2010 at 10:51, Richard Hipp d...@sqlite.org wrote:
My suggestion is that you make a copy of the os_unix.c source file (call
it
chromium_vfs.c or anything else that you like) and apply your
On Thu, Aug 26, 2010 at 6:02 PM, Paweł Hajdan, Jr.
phajdan...@chromium.orgwrote:
Please take a look at chromium_sqlite3 functions in
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/sqlite/src/src/os_unix.c?view=markup
They are needed because in Chrome the browser process will
On Fri, Aug 27, 2010 at 04:58, Richard Hipp d...@sqlite.org wrote:
The VFS interface is published, stable, and documented. I think the VFS is
the interface you should be using.
You do not have to patch os_unix.c. Leave it unchanged.
Sounds good to me. This is one of my goals - to avoid
Please take a look at chromium_sqlite3 functions in
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/sqlite/src/src/os_unix.c?view=markup
They are needed because in Chrome the browser process will pass a file
descriptor to the child renderer process instead of a file path. Here's the
15 matches
Mail list logo
