[libdmapsharing] Add comment about future of dmap_container_record_add_entry() Signed-off-by: W. Michael Petullo <mik

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

commit e6cc61479c287aa1a8d070163b1df5eace33871b
Author: W. Michael Petullo <mike flyn org>
Date:   Thu Mar 31 21:26:32 2011 -0500

    Add comment about future of dmap_container_record_add_entry()
    Signed-off-by: W. Michael Petullo <mike flyn org>

 libdmapsharing/dmap-container-record.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)
---
diff --git a/libdmapsharing/dmap-container-record.c b/libdmapsharing/dmap-container-record.c
index 2d1a227..2e70706 100644
--- a/libdmapsharing/dmap-container-record.c
+++ b/libdmapsharing/dmap-container-record.c
@@ -73,6 +73,10 @@ dmap_container_record_get_id (DMAPContainerRecord * record)
 	return DMAP_CONTAINER_RECORD_GET_INTERFACE (record)->get_id (record);
 }
 
+/* NOTE: record is not used in dmapd implementation, only ID. Should we get rid
+ * of record in next API generation? Should we add a function to explicitly set
+ * a pointer to the "whole" media database (in which the ID is valid)?
+ */
 void
 dmap_container_record_add_entry (DMAPContainerRecord * container_record,
 				 DMAPRecord * record, gint id)