Sqlite :- http://www.sqlite.org/
public domain embeddable sql library with a lot of language bindings. Apple shall be shipping this along with Tiger
http://www.apple.com/macosx/tiger/unix.html
Useful when you want a something more than BerkeleyDB but don't want the install/config of mysql and postgresql.
Libevent: http://www.monkey.org/~provos/libevent/
Event notification library which is also available in NetBSD and OpenBSD. Allows applications to be portable and use the most scalable event notification mechanism on each platform (kqueue for *BSD and epoll for Linux)
Regards, Yusuf
On Wed, 14 Jul 2004 10:34:39 +0800, Yusuf Goolamabbas wrote:
Sqlite :- http://www.sqlite.org/
public domain embeddable sql library with a lot of language bindings.
Why Core and not Extras? sqlite is provided by fedora.us already.
On Wed, Jul 14, 2004 at 10:48:35AM +0200, Michael Schwendt wrote:
On Wed, 14 Jul 2004 10:34:39 +0800, Yusuf Goolamabbas wrote:
Sqlite :- http://www.sqlite.org/
public domain embeddable sql library with a lot of language bindings.
Why Core and not Extras? sqlite is provided by fedora.us already.
PHP5 use sqlite I think. That may be one good reason to move it in core.
Daniel
Daniel Veillard wrote:
On Wed, Jul 14, 2004 at 10:48:35AM +0200, Michael Schwendt wrote:
On Wed, 14 Jul 2004 10:34:39 +0800, Yusuf Goolamabbas wrote:
Sqlite :- http://www.sqlite.org/
public domain embeddable sql library with a lot of language bindings.
Why Core and not Extras? sqlite is provided by fedora.us already.
PHP5 use sqlite I think. That may be one good reason to move it in core.
Another is that Mozilla/Firefox are likely going to require it soon and drop mork as its db engine. Shaver has been doing the work here.
Christopher Aillon (caillon@redhat.com) said:
Another is that Mozilla/Firefox are likely going to require it soon and drop mork as its db engine. Shaver has been doing the work here.
The de-bloat fan in me thinks that a good policy is to not ship libraries until they're actually required by apps that we ship.
Bill
On Wed, 2004-07-14 at 16:40 -0400, Bill Nottingham wrote:
Christopher Aillon (caillon@redhat.com) said:
Another is that Mozilla/Firefox are likely going to require it soon and drop mork as its db engine. Shaver has been doing the work here.
The de-bloat fan in me thinks that a good policy is to not ship libraries until they're actually required by apps that we ship.
I would also agree. Though things like this that can be quite useful do make for great entries in Fedora Extras and possibly pulled into Core in the future if/when they become a requirement for other packages.
On Wed, Jul 14, 2004 at 09:09:04PM -0700, Max K-A wrote:
PHP5 use sqlite I think. That may be one good reason to move it in core.
Actually, PHP5 *ships with* SQLLite. If we include SQLLite in Fedora, it means a modification of the PHP5 package to not include SQLLite.
In general it's better to reuse shared lib as much as possible, one of the reasons is memory footprint, but handling security updates is also a major one. You can't believe how much code has a copy of the zlib library and the horrible mess this generated. I think from a distribution point of view, the goal is really to make sure the code (and data) are shared for common libraries.
Daniel