[gstreamer-bugs] [Bug 396779] Preset interface for elements

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=396779

  GStreamer | gstreamer (core) | Ver: HEAD CVS




------- Comment #35 from Christophe Dehais  2007-11-21 17:35 UTC -------
true, that breaks my KISS strategy...
So let me tweak it:
On upgrade, the new default presets get installed system-wide and the old ones
(the user copy) stay untouched. The elements could declare a minimum version
number for preset files (the 2nd line of the proposed format), signal a need
for upgrade when trying to read the file and provide a merging mechanism.
The gst-preset-defaults could perform any update / merging and maybe get called
by packaging scripts. 
If its current version is ok, that means the user will not see any new presets
without calling explicitly the gst-preset-defaults tool (again a packaging
system could do it for him).

I don't think merging is too hard to do (easy to say, I admit): read user file,
build list of old presets, read new system file, build list of new presets, add
each preset of the new list to the old list (if it isn't already there). I
thought of the problem of new and missing properties, but isn't it a case of
API break ?

User presets may not be a too sensitive piece of information, so a
do_the_best_I_can strategy would seem sufficient to me.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=396779.