Re: [Tracker] Upcomming API review



I'm not sure something like this would be a great idea, unless there
were another method of storing the bookmarks. Users often have
preferences about more than just the bookmarks themselves (order,
expanded or not). Also, this would lead to some strange problems if
(for example) the user happened to download a file with that metadata
and tracker indexed it, or if another program used the same format or
something. It seems to me that the 'Right Thing' would be more to make
Epiphany store its bookmarks in something like XML, and have Tracker
be able to extract metadata directly from the bookmark file? Possibly
not (I haven't really looked at how Epiphany stores its bookmarks, so
I may be pulling **** out of my *** :-) A good frontend to Tracker
(which I'm thinking about writing) would have an option to turn on or
off bookmark indexing, which might also be better than having Epiphany
trying to autodetect Tracker.

Anyways, just my two cents. :-)

Cheers,
Samuel

On 8/10/06, Jamie McCracken <jamiemcc blueyonder co uk> wrote:
Mikkel Kamstrup Erlandsen wrote:
> 2006/7/8, Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com
> <mailto:mikkel kamstrup gmail com>>:
>
>     I did a review of the upcomming API and I generally find it really
>     good. I have a few comments/questions though... - This is not a real
>     critique, just loose ramblings :-)
>
>     Search interface:
>      - I must admit I don't quite grok the Query method. It looks like
>     powerful stuff, and is prolly just a documentation problem (or lack
>     of braincells on my behalf)
>
>     Files interface:
>      - Why would developers want to create a file at a specific size?
>      - What is the advantages of creating files through tracker? To
>     handle mime-stuff?
>
>     File signals:
>      - There has been a lot of wishes for recursive watches with inotify
>     but rlove has denied any patches. It does not look like Tracker can
>     give recursive watches in this API - perhaps it will be a welcome
>     addition?
>
>     Playlist interface:
>      - Perhaps this interface can be replaced by a general list of first
>     class objects? Maybe this is actually just a special form of
>     tagging... Anyway just a thought :-)
>
>
>
> I had another thought about Tracker usage... I'm posting to tracker-list
> just to make sure that the api can cover every possible use case I can
> think of :-)
>
> What if Epiphany wants to use tracker to store bookmarks in? It would
> probably do something like this:
>
>  1) Register WebBookmarks.url, WebBookmarks.title, WebBookmarks.foo,
> WebBookmarks.bar types if they are not already registered. Using
> GetRegisteredClasses() and checking if the array contains "WebBookmarks"??
> FIXME: Do RegisterType() not need a service to create the type on?
> Anyway - we need a service name to Get the data later on...
>
> 2) Get all WebBookmarks with bookmark_id_array = Search.Metadata
> ("Bookmarks", " WebBookmarks.url", "*", 0, 512), for each id get all
> metadata with bookmark_data = Metadata.Get("what_service", id, "*"),
> finally store all bookmark_data objects in a gtk.TreeStore with
> corresponding Tracker ids.
>
> 3) Subscribe to the "Changed" signal on the Metadata interface and use
> dbus filtering on some property (fixme: what property?) to receive only
> WebBookmarks changes. Update the treemodel  when signal is received.
>
> 4) When the user edits bookmarks use Metadata.set (foo), FIXME: How do
> we create a new bookmark?
>
> That should be all (modulo the fixmes),

We will have a dedicated bookmark dbus interface to make all the above
easy to do.

Eventually all first class objects will have their own interface


--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/

_______________________________________________
tracker-list mailing list
tracker-list gnome org
http://mail.gnome.org/mailman/listinfo/tracker-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]