Re: [Tracker] Announcing Daze: The Desktop Annotation Zebra

[Jamie McCracken <jamiemcc blueyonder co uk>]

Mikkel Kamstrup Erlandsen wrote:
> 2006/11/15, Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com 
> <mailto:mikkel kamstrup gmail com>>:
>
>     2006/11/15, Jamie McCracken <jamiemcc blueyonder co uk
>     <mailto:jamiemcc blueyonder co uk>>:
>
>         Mikkel Kamstrup Erlandsen wrote:
>         >  I just released a small note-taking/annotation tool for Gnome.
>         It uses
>         >  tracker to store all state, so has zero memory footprint
>         (unlike another
>         >  well known note application).
>         >
>         >  Read more at my blog: http://www.grillbar.org/wordpress/?p=173
>         >
>
>         I should really create some more methods so you can do this right.
>
>         First off we cant use "VFS Files" for this when we have "Notes"
>         as the
>         service. I will create a general method for creation that allows
>         you to
>         specify a service name.
>
>         We should have some predefined metadata Notes.Title,
>         Notes.Content etc
>
>         (they should be of type "indexable string" rather than just
>         "string" so
>         they show up in free text searches)
>
>         Ultimately I would want tomboy notes indexed too so hopefully
>         Daze has
>         enough in common
>
>         otherwise looking good!
>
>
>     Before we rush on regarding API changes, I have a few thoughts...
>
>     1) Files.Create could return (id,service) right now you pass it an
>     uri, but you are not guaranteed that this uri will be the actual
>     tracker id...

it should be

>     2) Likewise for Files.Exists. It could return (id,service) instead
>     of a boolean. - And an empty list if the file doesn't exist. Also
>     auto_create should make Files.Exists return (id,service) if the file
>     was created no? I think it would be more useful that way.

dunno if it says its successful then it means the given uri was used

>     3) Search.Metadata could take a list of metadata classes instead of
>     single class to make it more efficient.

if we make it extensible then we lose the precompiled query's simplicity 
and performance advantage. We would need a dynamic query + c code to 
build it up to handle multiple metadata which is more work and slower to 
preform. Still if its really needed then we will have to do it


>     4) Metadata.Get could take a list of uris, or maybe a list of
>     (uri,service) tuples. Currently it takes a single uri.

The output would be nasty for multiple uris though

a hash table is fine for one uri but not sure how it could easily extend 
to multiple efficiently


>     Generally, I want to make the interfaces more "compact", with the
>     methods providing richer information, and taking batch arguments as
>     default. The idea is to have a flexible api that minimizes the
>     amount of dbus traffic... 
>
>
>
> 5) There actually also need to be a way to set the mtime on an object. 
> Either by metadata attributes or with a Files.Touch method. Right now 
> there's no way to update the mtime field of a "dummy" file like my notes.

mtime only makes sense for files

a Notes.Modified metadata would be more appropriate in your case.


> 6) The whole Files interface would do better named Objects maybe..?

nope - they are all file specific

what you need is a create service that just takes a service name and 
uri. The file version does extra donkey work like set mtime, mime 
metadata etc



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