Bookmarks shared among desktop environments

[Philip Van Hoof]

On Mon, 2005-04-18 at 22:53 +0200, Philip Van Hoof wrote:


Also note that my current idea's about the implementation is that the
library will actually contain a fair amount of code here. So not just
wrapping a DBUS-call.

The foreach will first get all the items. The facade.get(key) call will
only fetch the information for the base-class value and islist will be
set true in case it's indeed a list.

So it will cache only if the list was fully needed. For moving and
removing items from the list, the application doesn't need to fetch all
the items in the list from the daemon. (and of course, for the
application developer this is an implementation detail of dconf)

Note that for bookmarks you'll need a tree-structure.

So

~.bookmarks.web.Default.00000.uri
~.bookmarks.web.Default.00001.uri
~.bookmarks.web.Personal.00000.uri
~.bookmarks.web.Personal.00001.uri

However. I'm still not sure whether bookmarks should go into the
configuration management system.

Doing tree structures is technically doable. A list in a list is also
technically doable. Easily if the facade.get(key) isn't going to have to
fetch all hierarchical data.


{a} = ~.bookmarks.web
[1]
- Get all the items in {a}

	- For each item that is a list
		- Create a folder
		- {a} = item.key
		- do 1 (recursively)

	- For each non-list item
		- Display it in folder item.parent


But I haven't figured out how to make hierarchically moves easily doable
using an API. And I'm not sure if a configuration system should really
support this type of stuff anyway (again: "the bookmarks" isn't really
"configuration" data).


list : value {
	private facade

	add (value, row)
	remove (row)

	add (value, row, transaction)
	remove (row, transaction)

	value get (row)

	move (row, other_list, dest_row)
	{
		t = this.facade.start_transaction()
		this.add (other_list.get(row), dest_row, t)
		other_list.remove (row, t)
		this.facade.commit_transaction (t)
	}
}

note: with GObjects would this be something like ... of course

List* list_move (List* list, gint row, List* other_list, gint dest_row)

(yes this is library stuff, not daemon stuff)


But again:
> ps. I'd keep this for the technical analysis part of the game.
> Nevertheless it's good to keep thinks like this in mind.

In fact should be first finish some more use-cases and then start
thinking about some first technical ideas and concepts. Perhaps draw an
UML diagram first. This will give a very good idea of how the
implementation and library will be for the application developers.


(I should stop dreaming about the implementation now)


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.pvanhoof.be/