[Tracker] Tracker in RTOS
Hi, i have been going through web to find out whether i can integrate tracker for indexing & searching for emails,multimedia,sms,contacts in an Real-Time Operating System or low-memory embedded environment. I am not getting why tracker is using sqlite if it's managing its own RDF-based in-memory data-store. should i be able to define my own metadata for particular format & from where i can retrieve metadata to process/stored it in list in another application. Regards, Remo ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Tracker in RTOS
On Tue, 2010-05-11 at 12:06 -0700, Remo Remo wrote: > Hi, > > i have been going through web to find out whether i can integrate > tracker for indexing & searching for emails,multimedia,sms,contacts in > an Real-Time Operating System or low-memory embedded environment. As long as you don't make tracker-store and tracker-miner-fs processes that are ran as SCHED_IDLE (or the schedule priority for RT tasks, if that's different on your system), else they might force the processes for which you are using an RT operating system to be scheduled at a lower priority than tracker-store and tracker-miner-fs (and that doesn't sound very good to me, as that way you basically loose the certainties for which you chose an RT operating system). For very low latency & fast response times we are investigating direct- access to our SQLite database. This will require implementing a custom page cache implementation for SQLite which we haven't finished yet. I'm mentioning this because once that direct-access mode is available, you can let your queries be executed by processes with RT priority (without having to involve tracker-store's process). Right now, however, when you do a synchronous query to tracker-store from a RT process, I think you'll automatically yield (as your process will end up waiting on a unix socket in libdbus, and that's afaik a yield already). So no problem here. But ... When using asynchronous queries you might have to let the RT prioritized process yield itself manually. Check out sched_yield(). Else I think you can deadlock yourself. > I am not getting why tracker is using sqlite if it's managing its own > RDF-based in-memory data-store. Because Tracker isn't managing its own RDF-based in-memory data-store.. Tracker's store is using SQLite for storing the RDF triples (and doesn't have any in-memory data-stores). Tracker also has a persistent journal, but this journal is only used for backup/restore and journal replay. Not for accessing the data during operation. We have no plans to implement our own RDF-based in-memory data-store. > should i be able to define my own metadata for particular format & > from where i can retrieve metadata to process/stored it in list in > another application. I don't know what you mean. Can you give your exact use-case? Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Tracker in RTOS
On Tue, 2010-05-11 at 21:19 +0200, Philip Van Hoof wrote: > On Tue, 2010-05-11 at 12:06 -0700, Remo Remo wrote: > > I am not getting why tracker is using sqlite if it's managing its own > > RDF-based in-memory data-store. > > Because Tracker isn't managing its own RDF-based in-memory data-store.. > > Tracker's store is using SQLite for storing the RDF triples (and doesn't > have any in-memory data-stores). Tracker also has a persistent journal, > but this journal is only used for backup/restore and journal replay. Not > for accessing the data during operation. > > We have no plans to implement our own RDF-based in-memory data-store. Sqlite supports in memory tables so should be trivial to support (if we decide to do so of course). IIRC Its just changing the db name to "memory" jamie ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
Re: [Tracker] Tracker in RTOS
On Tue, 2010-05-11 at 15:45 -0400, jamie wrote: > On Tue, 2010-05-11 at 21:19 +0200, Philip Van Hoof wrote: > > On Tue, 2010-05-11 at 12:06 -0700, Remo Remo wrote: > > > > I am not getting why tracker is using sqlite if it's managing its own > > > RDF-based in-memory data-store. > > > > Because Tracker isn't managing its own RDF-based in-memory data-store.. > > > > Tracker's store is using SQLite for storing the RDF triples (and doesn't > > have any in-memory data-stores). Tracker also has a persistent journal, > > but this journal is only used for backup/restore and journal replay. Not > > for accessing the data during operation. > > > > We have no plans to implement our own RDF-based in-memory data-store. > > Sqlite supports in memory tables so should be trivial to support (if we > decide to do so of course). IIRC Its just changing the db name to > "memory" I don't really see the point in this. If the tracker-store process exits you'd loose all data. Unless you'd journal replay all triples in at each startup. Which, even with memory-tables, will take quite a while at startup. And memory tables consume of course memory. So my meta.db is atm 800MB, so that would mean 800MB of memory usage. But yes, just adding "memory" to each create-table would do that. For a highly specialized device this could easily be done by searching for the string "CREATE TABLE" and replacing all occurrences with "CREATE MEMORY TABLE". Don't complain that tracker-store's memory usage goes ballistic. Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
