planning: add thoughts about foreign registry cache updates

docs/random/ensonic/draft-bufferpools.txt

@@ -4,7 +4,7 @@ BufferPools
 This document proposes a mechnism to build pools of reusable buffers. The
 proposal should improve performance and help to implement zero-copy usecases.
 
-Last edited: 2009-09.01 Stefan Kost
+Last edited: 2009-09-01 Stefan Kost
 
 
 Current Behaviour

docs/random/ensonic/draft-registry-change-hooks.txt

@@ -0,0 +1,53 @@
+Registry Change Hooks
+----------------------
+
+This document proposes a mechnism to register on registry updates.
+
+Last edited: 2009-11-09 Stefan Kost
+
+
+Current Behaviour
+-----------------
+
+When new plugins are installed or some are removed, the next application that
+runs rebuiilds the registry. Any application that runs later on won't know about
+it.
+
+
+Problem
+-------
+
+Some usecases need to cache gstreamer capabilities. They need to know when the 
+cache needs to be rebuilt. We could either export the registry mtime as api or
+do the following.
+
+
+Proposal
+--------
+We add a ~/.gstreamer-0.10/registry-hooks directory. Applications can install
+scripts there. When the registry is rebuild, those scripts are run async in no
+specific order. There is no feedback channel (return values, stdout/err).
+
+
+Examples
+---------
+
+gst-inspector
+-------------
+it would install a script that simply deletes its cachefile.
+
+gupnp
+-----
+it would install a script that runs gst-inspect-0.10 --print-plugin-auto-install-info
+and post process it.
+
+totem,banshee,rythmbox
+-----------------------
+they could tune the "MimeType=" lists in their desktop files
+
+
+Open Items
+----------
+Should we have a gst-registry-hook script with --install/--remove/--list actions
+to manage hooks?
+