[libdmapsharing] Release 2.0.0

[W. Michael Petullo <wmpetullo src gnome org>]

commit 2fee75565288c77539d135abedc38a970d5d4f13
Author: W. Michael Petullo <mike flyn org>
Date:   Fri Jul 16 12:17:10 2010 -0500

    Release 2.0.0
    
    The libdmapsharing patch has been accepted into Rhythmbox, so it is time
    to release libdmapsharing 2.0.0. 2.1 will be a development series, and
    I hope to include DACP support in the forthcoming stable 2.2.
    Signed-off-by: W. Michael Petullo <mike flyn org>

 Makefile.am   |    5 +++--
 README-Memory |   48 ++++++++++++++++++++++++++++++++++++++++++++++++
 TODO          |    2 ++
 configure.ac  |    4 ++--
 4 files changed, 55 insertions(+), 4 deletions(-)
---
diff --git a/Makefile.am b/Makefile.am
index 41ef2aa..569303f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,7 +14,8 @@ pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = $(pcfiles)
 
 EXTRA_DIST =				\
-	autogen.sh				\
-	libdmapsharing.pc.in
+	autogen.sh			\
+	libdmapsharing.pc.in		\
+	README-Memory
 
 CLEANFILES = $(pcfiles)
diff --git a/README-Memory b/README-Memory
new file mode 100644
index 0000000..e0d6365
--- /dev/null
+++ b/README-Memory
@@ -0,0 +1,48 @@
+This documents the effort to make dmapd and libdmapsharing more memory
+efficient.
+
+I found that dmapd used a significant amount of heap space while trying to
+port dmapd to OpenWRT on a WRT160NL router with 32 Megabytes of RAM. A
+2,419-song library caused dmapd on x86_64 to use 7,413,760 bytes of heap
+space after reading the library into memory. Furthermore, connecting to
+dmapd using a DAAP client and receiving a list of songs caused heap usage
+to increase to over 10 Megabytes. Note that this memory usage might be
+smaller on the WRT160NL due to its 32-bit architecture, but it is still
+significant in size.
+
+I use the following tools to troubleshoot memory issues:
+
+	grep heap /proc/PID/maps	(current heap size)
+	valgrind / memcheck		(memory leaks)
+	valgrind / massif		(max heap size and memory over time)
+	gdb
+	objdump -t OBJECT-FILE | grep -e "\.bss" -e "\.data" | sort -k5 
+		| c++filt | tail
+
+I have made the following changes in order to make dmapd more memory
+efficient:
+
+1. Replace the hash table-based DMAPDb implementation with a Berkeley
+Database implementation. This has not resulted in any improvement,
+so the hash table implementation is once again the default.
+
+2. Fixed several memory leaks after analysing with valgrind.
+
+	Heap without client connection: 3,940,352 bytes
+
+3. Implement database cache so that dmapd does not need to use GStreamer
+to read media metadata each time it is run.
+
+	Heap without client connection using DB cache: 3,346,432 bytes
+
+4. Replace the DMAPDb in the DMAPContainerRecord implementation with a
+GSList of ID's.
+
+	Heap without client connection using DB cache: 4,759,552 bytes
+
+5. Implement "stringletons" and fix errors in 4) above.
+
+	Heap without client connection using DB cache: 2,854,912 bytes
+	Heap without client connection: 3,518,464 bytes
+	Heap after client connection and song list: 6,864,896 bytes
+	Max heap usages (massif): 8,945,760 bytes
diff --git a/TODO b/TODO
index 77be913..8da2c98 100644
--- a/TODO
+++ b/TODO
@@ -1,3 +1,5 @@
+Reduce the memory usage while building response to media list query.
+
 iTunes '09, segfault:
 	dmap_container_record_get_entry_count:86
 	_dmap_share_add_playlist_to_mlcl:1016
diff --git a/configure.ac b/configure.ac
index 501f0b9..141c479 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,8 +1,8 @@
-AC_INIT(libdmapsharing, 1.9.0.21)
+AC_INIT(libdmapsharing, 2.0.0)
 
 dnl when going to/from release please set the nano (fourth number) right !
 dnl releases only do Wall, cvs and prerelease does Werror too
-AS_VERSION(libdmapsharing, LIBDMAPSHARING, 1, 9, 0, 21, LIBDMAPSHARING_CVS="no", LIBDMAPSHARING_CVS="yes")
+AS_VERSION(libdmapsharing, LIBDMAPSHARING, 2, 0, 0, LIBDMAPSHARING_CVS="no", LIBDMAPSHARING_CVS="yes")
 
 AM_INIT_AUTOMAKE