On Tue, Aug 31, 2010 at 19:51, Richard Hipp 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 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.
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.
On Wed, Sep 1, 2010 at 10:20 PM, Max Vlasov 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
> 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
>
> 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
2010/8/31 Richard Hipp
> 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
On Tue, Aug 31, 2010 at 1:56 PM, Paweł Hajdan, Jr.
wrote:
> On Tue, Aug 31, 2010 at 10:51, Richard Hipp 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
On Tue, Aug 31, 2010 at 10:51, Richard Hipp 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:19 PM, Paweł Hajdan, Jr.
wrote:
> On Fri, Aug 27, 2010 at 18:27, Paweł Hajdan, Jr. >wrote:
>
> >
> >
> >> At start-time, simply call sqlite3_vfs_register() to register your
> >> customized VFS with SQLite.
> >>
> >
> >
> 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
On Fri, Aug 27, 2010 at 18:27, Paweł Hajdan, Jr. wrote:
>
>
>> At start-time, simply call sqlite3_vfs_register() to register your
>> customized VFS with SQLite.
>>
>
> That's what our implementation effectively does, see
>
On Fri, Aug 27, 2010 at 04:58, Richard Hipp 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
On Thu, Aug 26, 2010 at 6:02 PM, Paweł Hajdan, Jr.
wrote:
> 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
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