Added support for using keyrings on removable drives Fixes bug #454390

	* common/gkr-dbus.c: (split from daemon/gnome-keyring-daemon-dbus.c)
	* common/gkr-dbus.h: (added)
	* common/gkr-location.c: (added)
	* common/gkr-location.h: (added)
	* common/Makefile.am:
	* daemon/gnome-keyring-daemon-dbus.c:
	* daemon/gnome-keyring-daemon-io.c:
	* daemon/gnome-keyring-daemon-ops.c:
	* keyrings/gkr-keyring.c:
	* keyrings/gkr-keyring.h:
	* keyrings/gkr-keyrings.c:
	* keyrings/gkr-keyrings.h:
	* library/gnome-keyring.h:
	* tests/Makefile.am:
	* tests/unit-test-async.c:
	* tests/unit-test-keyrings.c:
	* tests/unit-test-location.c: (added)
	* configure.in:
	* HACKING: Added support for using keyrings on removable drives
	Fixes bug #454390

svn path=/trunk/; revision=721

1 files changed, 26 insertions, 3 deletions

diff --git a/HACKING b/HACKING
index 8131e1d2..4ffdde33 100644
--- a/HACKING
+++ b/HACKING
@@ -23,10 +23,32 @@ ui
    Prompting the user, asking for passwords. 
    
 
-USE OF THREADS
+--------------------------------------------------------------------------------
+                    USING 'LOCATIONS' INSTEAD OF FILE PATHS
 
-Gnome Keyring uses threads in a limited manner, as state machines, or execution
-stacks. Only one thread runs at any given time, each thread hands off execution
+Gnome Keyring supports having keyrings on removable media. Because removable
+media can be mounted in different mount-points, and for other related reasons,
+what's called a 'location' is used instead of a file point.
+
+Locations are like paths relative to a base. For example certain locations 
+might be relative to a home directory, and others might be relative to a USB
+drive.
+
+Location functionality:
+
+   common/gkr-location.h
+   
+Common functions:
+
+   gkr_location_from_path ()
+   gkr_location_from_child ()
+   gkr_location_to_path ()
+   
+--------------------------------------------------------------------------------
+                            USE OF WORKER THREADS
+
+Gnome Keyring uses threads in a limited manner, as state machines, (ie: execution
+stacks). Only one thread runs at any given time, each thread hands off execution
 to another thread. 
 
 The *only* use of threading and/or synchronization primitives should be in:
@@ -40,3 +62,4 @@ If a thread needs perform a blocking syscall, or do something that takes a long
 time (like create a key) it can use the gkr_async_begin_concurrent() and 
 gkr_async_end_concurrent() functions. While running 'concurrent' no global
 functions and/or data should be accessed.
+