Configuration API

Sean Middleditch elanthis at awesomeplay.com
Mon May 3 16:20:50 EEST 2004


On Mon, 2004-05-03 at 04:53, Dave Cridland [Home] wrote:

> > And based on that earlier discussion... are structs _really_ needed, or
> > should the API just provide a few functions that make it very easy to
> > simulate structs in the key heirarchy?  I.e., where we might have a list
> > of structs in a more complex model, a simpler model would just have a
> > set of sub-trees and a method to query the names of those trees.  (i..e,
> > give me all the sub-trees in /myapp/list-of-structs/)  The only problem
> > I could see with that approach is that where a list would provide
> > guaranteed ordering of items (at least that's how I think the list
> > should/would work), sub-trees would *not* have this quality (this is a
> > sensible design choice given how we want pluggable backends, and many
> > such backends could not support this quality).  Anyone needing an
> > ordered list of complex data types would, without having structs, need
> > to compose a list that simply held the names of the aforementioned
> > sub-trees, and manually keep them in sync.  (not pretty.)
> > 
> 
> Hmmm... I see.
> 
> Couldn't the application simply add a further member to each struct to be 
> used as a sort order?

That would require the app to read in all the keys, sort them, and then
select the index it wanted.  I'm not sure this is something real apps
actually need to worry about, though.  Some examples of this scenario
occurring in real life would be useful.  If any exist.  ;-)

> 
> And if it's doing this, is there any need for structs at all? It's just 
> increasing complexity, in a lot of ways.
> 
> Feel free, though, to substitute 'application' with 'upper-level API' at any 
> stage.
> 
> Dave.
> 
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.





More information about the xdg mailing list