9:34 p.m.
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
3:48 a.m.
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.
4:48 a.m.
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 | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
9:24 a.m.
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.
3:40 p.m.
Christopher Aillon (caillon(a)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
4:36 p.m.
On Wed, 2004-07-14 at 16:40 -0400, Bill Nottingham wrote:
Christopher Aillon (caillon(a)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.
--
David T Hollis <dhollis(a)davehollis.com>
4:45 a.m.
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
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
7223
days inactive
7224
days old
7 comments
7 participants
participants (7)
-
Bill Nottingham -
Christopher Aillon -
Daniel Veillard -
David Hollis -
Max Kanat-Alexander -
Michael Schwendt -
Yusuf Goolamabbas