Re: [Tracker] The org.freedesktop.Tracker.Files.Create method
2008/7/3 Philip Van Hoof [EMAIL PROTECTED]: Hi there, The indexer-split is all about moving the indexer to another process and letting trackerd perform no writes itself. Right now will the method org.freedesktop.Tracker.Files.Create trick trackerd into writing a record. it doesn't even matter whether or not that record is real (whether or not it's a thing that exists, is not even seriously checked for). We feel strange about letting the indexer index this. The indexer's architecture is built around the concept of indexing things that are real and that therefore exist. We also feel strange about letting trackerd write a thing that doesn't necessarily exist in the database. In fact, we feel strange about letting trackerd write anything. On top of that, I personally question the use of this method. Wouldn't a org.freedesktop.Tracker.Files.Check be better here? Such an API would illustrate to the indexer (via trackerd) that it should better go check something. Like a VFS directory that might indeed not be in the module's configuration as path-to-index. Just adding arbitrary 'stuff' is going to confuse the indexer in all sorts of interesting ways (like, the setting up of monitors on something that doesn't exist, yet can't be auto-removed, yet must be returned if there was a match yet doesn't seem to have any data to search for other than simple meta data). So what do we do with this capability? Daze[1] actually use org.freedesktop.Tracker.Files.Exist to store user annotations directly in Tracker. So the API is indeed of use. However another incarnation of it may be more in order. With my Xesam hat on I imagine that the Xesam Metadata Storage spec is going to have something like: CreateRecord (content, source, fields) Where one could store a purely virtual record in the db. The indexer should automatically pick this up somehow. I have not really thought the API through so please don't take CreateRecord to seriously. I do however see the need for something along those lines. Cheers, Mikkel [1]: Daze was a part-serious part-sample application I stirred together to test Tracker. See http://www.grillbar.org/wordpress/?p=173 ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] The org.freedesktop.Tracker.Files.Create method
On Fri, 2008-07-04 at 11:00 +0200, Mikkel Kamstrup Erlandsen wrote: 2008/7/3 Philip Van Hoof [EMAIL PROTECTED]: Daze[1] actually use org.freedesktop.Tracker.Files.Exist to store user annotations directly in Tracker. So the API is indeed of use. However another incarnation of it may be more in order. The Files namespace would indicate to me that it's strictly about files. Unless the file must be created doesn't Files.Create make a lot of sense to me. Files.Exist should be called Files.IsIndexed. If Files.Create is for creating arbitrary records that don't necessarily represent a thing like a real file, I personally would call it something like: Arbitrary.Create or Objects.Create or Indexables.Create Files.Create right now puts something in file-meta.db, but file-meta is clearly for real files-only. Maybe a arbitrary-meta.db is in place. With my Xesam hat on I imagine that the Xesam Metadata Storage spec is going to have something like: CreateRecord (content, source, fields) CreateRecord would make sense, except that it tells too much about the implementation detail of 'records' being used, in my opinion. For the user of Xesam, it doesn't matter how the indexer stores things. Where one could store a purely virtual record in the db. The indexer should automatically pick this up somehow. I have not really thought the API through so please don't take CreateRecord to seriously. I do however see the need for something along those lines. Okay :) [1]: Daze was a part-serious part-sample application I stirred together to test Tracker. See http://www.grillbar.org/wordpress/?p=173 Sure, we can probably adapt it easily to start using a more meaningful remote Tracker API? :) -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] The org.freedesktop.Tracker.Files.Create method
Philip Van Hoof wrote: On Fri, 2008-07-04 at 11:00 +0200, Mikkel Kamstrup Erlandsen wrote: 2008/7/3 Philip Van Hoof [EMAIL PROTECTED]: Daze[1] actually use org.freedesktop.Tracker.Files.Exist to store user annotations directly in Tracker. So the API is indeed of use. However another incarnation of it may be more in order. The Files namespace would indicate to me that it's strictly about files. Unless the file must be created doesn't Files.Create make a lot of sense to me. Files.Exist should be called Files.IsIndexed. If Files.Create is for creating arbitrary records that don't necessarily represent a thing like a real file, I personally would call it something like: Arbitrary.Create or Objects.Create or Indexables.Create Files.Create right now puts something in file-meta.db, but file-meta is clearly for real files-only. Maybe a arbitrary-meta.db is in place. With my Xesam hat on I imagine that the Xesam Metadata Storage spec is going to have something like: CreateRecord (content, source, fields) CreateRecord would make sense, except that it tells too much about the implementation detail of 'records' being used, in my opinion. For the user of Xesam, it doesn't matter how the indexer stores things. Where one could store a purely virtual record in the db. The indexer should automatically pick this up somehow. I have not really thought the API through so please don't take CreateRecord to seriously. I do however see the need for something along those lines. Okay :) [1]: Daze was a part-serious part-sample application I stirred together to test Tracker. See http://www.grillbar.org/wordpress/?p=173 Sure, we can probably adapt it easily to start using a more meaningful remote Tracker API? :) I agree with you Phillip, but I have a feeling this will have to be fixed AFTER the initial release after merging with TRUNK. This being that we can really only break API for applications like this in major releases. At least that is what Jamie will say I am sure :) This isn't the only API in this case. I did post a list of DBus calls to Jamie a while back (I think you were on it Phillip) which do nothing or need removing. We will have to add this one to the list and probably wait for 0.7. -- Regards, Martyn ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] The org.freedesktop.Tracker.Files.Create method
2008/7/4 Philip Van Hoof [EMAIL PROTECTED]: On Fri, 2008-07-04 at 11:00 +0200, Mikkel Kamstrup Erlandsen wrote: 2008/7/3 Philip Van Hoof [EMAIL PROTECTED]: Daze[1] actually use org.freedesktop.Tracker.Files.Exist to store user annotations directly in Tracker. So the API is indeed of use. However another incarnation of it may be more in order. The Files namespace would indicate to me that it's strictly about files. Unless the file must be created doesn't Files.Create make a lot of sense to me. Files.Exist should be called Files.IsIndexed. If Files.Create is for creating arbitrary records that don't necessarily represent a thing like a real file, I personally would call it something like: Arbitrary.Create or Objects.Create or Indexables.Create Files.Create right now puts something in file-meta.db, but file-meta is clearly for real files-only. Maybe a arbitrary-meta.db is in place. With my Xesam hat on I imagine that the Xesam Metadata Storage spec is going to have something like: CreateRecord (content, source, fields) CreateRecord would make sense, except that it tells too much about the implementation detail of 'records' being used, in my opinion. For the user of Xesam, it doesn't matter how the indexer stores things. I don't want to store things in the Index. I want to store it in something that I as a developer can think of as a persistent data store. An abstract place where I can shovel data into and later search and retrieve it, and be confident that the data is not lost if the user upgrades her distribution or what ever. Therefore the Record metaphor makes good sense to me. Where one could store a purely virtual record in the db. The indexer should automatically pick this up somehow. I have not really thought the API through so please don't take CreateRecord to seriously. I do however see the need for something along those lines. Okay :) [1]: Daze was a part-serious part-sample application I stirred together to test Tracker. See http://www.grillbar.org/wordpress/?p=173 Sure, we can probably adapt it easily to start using a more meaningful remote Tracker API? :) Sure. I am not opposing a deprecation or removal of the Files.Create (and friends) API of Tracker. Just pointing out the features they provide are in fact useful. Cheers, Mikkel ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] The org.freedesktop.Tracker.Files.Create method
I think it might be better to call it CreateEntity rather than CreateFile alos CreateFile was really for adding metadata against Gnome VFS files which tracker could not see - with GIO usage in tracker this is no longer relevant On Fri, 2008-07-04 at 11:27 +0200, Mikkel Kamstrup Erlandsen wrote: 2008/7/4 Philip Van Hoof [EMAIL PROTECTED]: On Fri, 2008-07-04 at 11:00 +0200, Mikkel Kamstrup Erlandsen wrote: 2008/7/3 Philip Van Hoof [EMAIL PROTECTED]: Daze[1] actually use org.freedesktop.Tracker.Files.Exist to store user annotations directly in Tracker. So the API is indeed of use. However another incarnation of it may be more in order. The Files namespace would indicate to me that it's strictly about files. Unless the file must be created doesn't Files.Create make a lot of sense to me. Files.Exist should be called Files.IsIndexed. If Files.Create is for creating arbitrary records that don't necessarily represent a thing like a real file, I personally would call it something like: Arbitrary.Create or Objects.Create or Indexables.Create Files.Create right now puts something in file-meta.db, but file-meta is clearly for real files-only. Maybe a arbitrary-meta.db is in place. With my Xesam hat on I imagine that the Xesam Metadata Storage spec is going to have something like: CreateRecord (content, source, fields) CreateRecord would make sense, except that it tells too much about the implementation detail of 'records' being used, in my opinion. For the user of Xesam, it doesn't matter how the indexer stores things. I don't want to store things in the Index. I want to store it in something that I as a developer can think of as a persistent data store. An abstract place where I can shovel data into and later search and retrieve it, and be confident that the data is not lost if the user upgrades her distribution or what ever. Therefore the Record metaphor makes good sense to me. Where one could store a purely virtual record in the db. The indexer should automatically pick this up somehow. I have not really thought the API through so please don't take CreateRecord to seriously. I do however see the need for something along those lines. Okay :) [1]: Daze was a part-serious part-sample application I stirred together to test Tracker. See http://www.grillbar.org/wordpress/?p=173 Sure, we can probably adapt it easily to start using a more meaningful remote Tracker API? :) Sure. I am not opposing a deprecation or removal of the Files.Create (and friends) API of Tracker. Just pointing out the features they provide are in fact useful. Cheers, Mikkel ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
