Conclusions and a compact list of requirements for deconf-spec

[Philip Van Hoof]

On Sat, 2005-12-10 at 14:53 +0000, Jamie McCracken wrote:
> Philip Van Hoof wrote:
> > Hi there,
> > 
> > Today somebody asked an interesting question about it (in private) and
> > the recently started Portland project is also a good reason why to
> > repeat some stuff.
> >  
> 
> Its cool you are still perservering with this.
> 
> A few thoughts - is it the schema thats holding up consensus?
> 
> As a developer, I would apreciate needing minimal effort to implement 
> schemae (ie they should be concise and involve minimal typing). It would 
> help if you could show if this is the case with your proposal as Im sure 
> a lot of developers will give it the thumbs up if so.
> 
> The API looks good and usable. So I take it the plan is for each desktop 
> to implement its own daemon and config library which meets that spec.
> 
> Im not sure where deconf fits into this? Are you still planning to 
> create a desktop neutral daemon which would be very hard and time 
> consuming with all the abstractions (threads, modules, mainloop et al)?

Alright .. quick notes on deconf-desk. But don't start flame wars about
it. It ain't worth it.

It has been asked to build a demo implementation. "deconf-desk" fits in
that role. But rather than a quick'n dirty implementation, I'm actually
planning to create a great implementation (some day). I have a few very
good idea's about both improving performance and memory usage and about
making it network transparent. Which is, in my humbly opinion, far more
important than technology dependencies, speed performance and memory
usage these days. Those last ones are the only ones that people dare to
talk about. It's my opinion that they are trying to fix the wrong
problems. However, I do agree that memory consumption is important when
building a daemon fit for doing the configuration of a CURRENT mobile
device.

I'm also planning to some day propose a specification for the network
transparency. One thing is certain: The forced demand that schema's are
to be handled by the clients AND ONLY BY THE CLIENTS is making it nearly
impossible to create a secure type safe network transparent
configuration system. Yet this is a top request in the field of
independent software vendors and (because of) IT departments that have
the responsibility of managing A LOT desktops at their workspace.

There's better ways to handle type safety (schemas). It's a cheap way to
get rid of the problems GConf has with performance and memory usage,
mainly caused by the current schema handling, by moving the problem to
the hands of the desktop application developers. Also the possibility of
caching of such schema's (and reusing the cache between processes in a
clean platform independent way -- so shared memory isn't an option) is
now eliminated.


-- 
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be