Bookmarks shared among desktop environments

[Jamie McCracken]

Philip Van Hoof wrote:
> On Mon, 2005-04-18 at 18:19 +0100, Jamie McCracken wrote:
> 
>>Philip Van Hoof wrote:
> 
> 
>>>Agreed bookmarks are very close to configuration data (preferences), in
>>>fact they are application-data. That's because they are created because
>>>of interaction with the user.
>>>
>>>Preferences are more static: The user sets them, and then works with the
>>>application that will play by the rules it can read from these settings.
>>>
>>>So it's not a valid use-case to add bookmarks to the configuration data.
>>
>>I see little difference. Recent file lists, bookmarks - these are all 
>>prefs or config options even if they are set automonously. It is 
>>desirable to have one storage facility for all these so why not DConf?
> 
> 
> If DConf needs to solve this, DConf will be even more complex to both
> implement and to get it adopted. You will not only be asking to
> application developers: "Hey, change your configuration system!" but
> also "Hey, make sure that you from now on use this specific system for
> putting that specific application data in!".
> 

Not in one step - it would be evolutionary. Dconf is about providing the 
mechanism/infrastructure for this to happen if its desirable. THeres no 
need to worry about thi for Dconf though.

> Are you prepared to redo most of the evolution-data-server project? Is a
> Novell/Ximian developer working on Evolution going to do it? Will
> Firefox/Mozilla and Konqueror/Safari and Galeon/Epiphany adopt this?
> 
> That's asking for quite a lot adoption.
> 
> You will need to talk to a huge amount of application developers. This
> way it will take a lot longer to both implement it and to get it
> adopted.
> 
> In other words: DConf will be more likely only vaporware.

I disagree. Im not saying DConf will or should make this sort of thing 
dependable on its success. Rather its something that would be decided 
upon *after* DConf is a success. It should not concern the actual 
development of DConf at this point.

> 
> 
>>What we need as Avery pointed out is a standard shareable key structure 
>>to accomplish this.
> 
> 
> 
> Indeed
> 
> [CUT]
> 
> 
>>its trivial for db backends like sqlite. Specify an xml schema and you 
> 
> 
> One thing I learned from my experience as a software developer (as a
> profession) is that nothing is trivial (and telling your customer
> something is trivial is like shooting yourself through the head rather
> than just your foot).
> 
> You really want to take a look at the "sharing calendaring and contact
> information" of evolution-data-server to know the needs for such a
> system. Perhaps it's better to reuse that software project, perhaps not.
> 
> I don't think a simple sqlite table (file) and some standarization is
> going to do the job.

It will technically (whether the parties concerned adopt it is a 
different matter) but again this is orthogonal to Dconf atm.



> 
> 
> 
>>should be able to generate a table for it (ditto with xml databases). Im 
>>willing to do all the extra work for this but recognise that its only 
>>really applicable to relational databases (as opposed to KVP's like LDAP 
>>and Bereley DB) so we need to be careful as strucured data access might 
>>not be as network transparent if you relied upon LDAP (although you 
>>could put the db on an NFS mount or use a client/server RDBMS if you 
>>really did need this).
> 
> 
>>Whilst you could restrict Dconf to key value pairs, the benefits of more 
>>structured storage are more obvious to other things like the mime type 
>>database, address books and all the other freedesktop storage mechanisms 
>>(menues, session variables et al).
> 
> 
> I don't think the configuration system needs "structured types". The
> most advanced type is perhaps the LIST-type. Which is a list of simple
> values.
> 
> Imagine the complexity of the API to read complex types from this config
> system.

Not that complex - the result set would be an array of an array of 
values (IIRC Dbus supports this). Im not saying DConf needs to have this 
in its initial releases but for the future it might be desirable.


> 
> 
>>I do believe strongly that we need a global config system and not the 
>>current mess of dot files, xml files, session vars et al that are 
>>currently used.
> 
> 
> Okay

so if not DConf then something else but what I would hate to see is a 
separate daemon for this and another for that. We dont need EDS or 
bookmark deamons if we have a generic storage facility for structured 
data. One daemon, one store and one set of config tools sounds a lot 
more practical and manageable. Im not objecting to Christian pursuing a 
Dbus daemon for bookmarks at all because none of this infrastructure 
exists at the moment.

jamie.