xfconf data type quesions

[Brian J. Tarricone]

Hey all,

I was looking at libxfce4mcs-client, as I intend to (later) write a
dummy implementation that forwards requests off to libxfconf.  However,
I've hit a slight roadblock: McsColor.  Sorry, this post is pretty
long; hopefully not painfully so.  I see a few options:

1.  Store McsColors as an Xfconf string list (with the ints converted to
strings):

<property name="mycolor1" type="strlist">
  <string>9312</string>
  <string>42</string>
  <string>20933</string>
  <string>65535</string>
</property>

Pros: simple and easy to implement.
Cons: kinda kludgy; not 'type-safe'; not obvious to app authors who
later migrate to libxfconf how their old color is stored.


2.  Store McsColors as multiple Xfconf int properties hidden to the
libxfce4mcs-client and libxfconf user. So something like:

<property name="mycolor1____mcscolor_red" type="int" value="9312"/>
<property name="mycolor1____mcscolor_green" type="int" value="42"/>
<property name="mycolor1____mcscolor_blue" type="int" value="20933"/>
<property name="mycolor1____mcscolor_alpha" type="int" value="65535"/>

Pros: maintains the type of the values.
Cons: looks ugly and kludgy; if the app migrates to Xfconf later, the
values will be there and will be more or less unusable (i.e., a request
for '/foo/mycolor1' will give nothing).


3.  Add an XfconfColor type to the Xfconf spec.

<property name="mycolor1" type="color">
  <red>9312</red>
  <green>42</green>
  <blue>20933</blue>
  <alpha>65535</alpha>
</property>

... or just a packed string representation:

<property name="mycolor1" type="color" value="9312;42;20933;65535"/>

Pros: solves the problem nicely and provides the same functionality tha
MCS did; obvious to app authors migrating to libxfconf how to access
their previously-stored McsColors.
Cons: a color data type seems a bit special-purpose and sounds like
it's only there to provide backward-compat.


4.  Allow client libraries to define their own custom types that are
just stored blindly by the daemon (perhaps as binary data).  Add an
XfconfColor type to libxfconf only, and have it handle converting the
custom data into a color.

<property name="mycolor1" type="custom-xfce-color"
          value="[some kind of binary data]"/>

Pros: allows for other types of custom data to be stored without
needing to update the daemon or the backend spec/interface; obvious to
app authors migrating to libxfconf how to access their
previously-stored McsColors.
Cons: makes some properties specific to the particular implementation
of the client library.


5.  Pack the four 16-bit values of the McsColor into an int64 and store
it like that natively in the config store.  The libxfce4mcs-client <->
libxfconf bridge library will know how to convert between the two, and
will assume that int64 values are always McsColors (because MCS doesn't
know how to deal with 64-bit ints).

<property name="mycolor1" type="int64" value="2621095164890185727"/>

Pros: no need to change Xfconf at all; nice neat solution; apps that
later migrate to libxfconf can still use the color value
Cons: app authors that later migrate to libxfconf will need to know
that the stuff that used to be McsColors are just packed 64-bit ints
now, and will have to do conversion manually (though this is probably
what they'd have to do anyway, unless they choose to use 4 separate
properties for colors).


6.  Extend the Xfconf spec to allow lists of arbitrary data types (not
just string lists as we have now)  The MCS lib bridge will just assume
that a request for a property that turns out to be an array of 4 ints
is a color.  MCS doesn't know about arrays anyway, so it wouldn't have
anything else to do with the data.

<property name="mycolor1" type="array:int">
  <int>9312</int>
  <int>42</int>
  <int>20933</int>
  <int>65535</int>
</property>

(Or just type="array" and allow arrays to store mixed-type elements.)

Pros: colors can just be stored as a list of 4 ints; apps that later
migrate to libxfconf can still use their color values; opens up
possibilities for other apps to store arrays of data.
Cons: app authors migrating to libxfconf need to know that this is how
their McsColors are now stored; bloats libxfconf API with array type
getters and setters for each data type.


That's all I can think of offhand.  I'm kinda leaning toward #6,
though #5 might be ok as well.  #6 could also be useful for a variety
of other things, e.g. storing lists of boolean flags, (x,y) coords for
points, (x,y,w,h) sets for rectangles, etc.

Can anyone think of any other options, or reasons why #1-4 (and 5)
might be better than #6.  If not, I'll probably go with #6.  Assuming
#6, can anyone think of a good API for libxfconf that lets people set
both single values and arrays (of all data types) without having to
have getters/setters for everything, but is still convenient and
doesn't look ugly?

I'm thinking of something like this:

void xfconf_channel_set_array(XfconfChannel *channel,
                              const gchar *property,
                              XfconfDataType type,
                              GValue **values,
                              gint n_values);

... where I'd define an XfconfDataType enum for string, int, etc.  I
don't want to use GValues in the public API, though I suppose I'm
already tied to GObject (since XfconfChannel is a GObject), so maybe
that's ok.  In lieu of an XfconfDataType enum, could just use raw
GTypes (G_TYPE_STRING, G_TYPE_INT, etc.), though I dislike exposing
that functionality, and library users could always try to do silly
things like try to store a list of G_TYPE_OBJECT, which obviously won't
work.  I'm not really happy with this.

I suppose it would be ok to have 4 functions per data type - set value,
get value, set array, get array, though times 5 data types, that's 20
functions just for setting and getting properties (well, 21 if you count
xfconf_channel_get_all_properties()).  I dunno.  I'm torn.

Anyhow, I'd best go to bed before I ramble on any more.

	-brian