Active Topics

 



Notices


Reply
Thread Tools
Posts: 10 | Thanked: 4 times | Joined on Jan 2010 @ Washington, DC
#31
i would at least like to search my emails. =)
 
Posts: 219 | Thanked: 94 times | Joined on Nov 2009 @ Helsinki, Finland
#32
Brainstorm anyone? What kind of contents need to be searched, e.g. files, file metadata, emails, SMS, IM etc... How to implement indexing, and what kind of search interface to provide? Should the search results be filtered by type of the content, size, date range etc. How to open the specific search results, is it possible to jump to certain SMS or email?
__________________
Ham > Turkey
 

The Following User Says Thank You to naabi For This Useful Post:
Posts: 21 | Thanked: 10 times | Joined on Jan 2010 @ Madrid
#33
Originally Posted by naabi View Post
Brainstorm anyone?
Why not first look at how search is implemented on iPhone, Symbian, Android, WebOS etc and then take it from there?
 
Posts: 12 | Thanked: 13 times | Joined on Feb 2010
#34
Originally Posted by SkyEagle View Post
For battery usage we could implement an option to index only when connected to the power/USB cable.
But other OS/phones (like Iphone) have found the solution.
Indeed it is really strange that there is no Linux good search app like google desktop on windows platform and that no Guru programmer have coded something similar (even not so fast).

More over I don't understand why we don't take full use of the internal DB where are stored email, sms, contacts etc, making also a local search much more complete (example in company, notes field etc). We need more option to fully configure how and where we want to search.
Totally agree - Apple has it with iPhone and it's quite frankly possibly the *best* iPhone feature. How can Apple have found a way for instant search without killing the battery and the collective might of the open source community haven't?

It's not rocket science - the initial index is OK to max out the CPU. Thereafter, monitor the filesystem with inotify (or whatever the Maemo equivalent is) such that any writes will be spotted and indexed regardless of where. Contacts, SMS, Calendar, etc don't need to be actively indexed since their databases can be queried directly.

The only overhead in normal use will be when other apps are writing, and even then it can be minimised.

There is really no reason why instant search should be such a big power drain. The real problem is that everybody is accustomed to desktop applications where CPU time is essentially unlimited, and power limits simply don't exist. When it comes to mobile platforms, too many people assume the limitations mean it can't be done. The N900 is more powerful and with a better battery (in my experience as an ex-iPhone owner) than the iPhone yet Apple managed it, so why can't we?
 

The Following User Says Thank You to rivierakid For This Useful Post:
Posts: 219 | Thanked: 94 times | Joined on Nov 2009 @ Helsinki, Finland
#35
Originally Posted by rivierakid View Post
Totally agree - Apple has it with iPhone and it's quite frankly possibly the *best* iPhone feature. How can Apple have found a way for instant search without killing the battery and the collective might of the open source community haven't?
It's also possible that all data pushed to device using iTunes is indexed by the the iTunes itself.

I guess for N900 the existing tracker is a good tool, but there's no point running two similar processes for global search and media indexing that already exists. Tracker has quite nice support for indexing file contents of different types of files. I have no idea how to add support for e.g. emails. Another issue is the somewhat outdated version of current tracker.
__________________
Ham > Turkey
 

The Following User Says Thank You to naabi For This Useful Post:
Posts: 12 | Thanked: 13 times | Joined on Feb 2010
#36
Originally Posted by naabi View Post
It's also possible that all data pushed to device using iTunes is indexed by the the iTunes itself.

I guess for N900 the existing tracker is a good tool, but there's no point running two similar processes for global search and media indexing that already exists. Tracker has quite nice support for indexing file contents of different types of files. I have no idea how to add support for e.g. emails. Another issue is the somewhat outdated version of current tracker.
I agree it's possible the initial index may be performed by iTunes, the iPhone absolutely does search across new content. Of course, Calendars, Contacts, Notes, SMS, etc are all in sqlite databases on iPhone so yeah - there's very little "indexing" as such, but then that just makes it all the more egregious that the N900 has nothing by default for the same things.

Like I say above, extending this to the entire filesystem via inotify really shouldn't be such a big problem, although I don't agree that indexing should not occur while on battery - it's a mobile device that spends over 75% of it's time on battery. You need to be able to index those items you receive (when you receive them) while on battery too.

Last edited by rivierakid; 2010-03-10 at 09:16. Reason: Fixed typo
 

The Following 2 Users Say Thank You to rivierakid For This Useful Post:
Posts: 219 | Thanked: 94 times | Joined on Nov 2009 @ Helsinki, Finland
#37
What is lost if SPARQL is not used? Is the search from index missing the information provided by ontologies, or is this already lost when indexing.

One good question is that what kind of indexing is used in Meego? Moblin uses Bickley for indexing and providing search API.
__________________
Ham > Turkey
 
Posts: 247 | Thanked: 91 times | Joined on Jan 2008 @ London/M4 Corridor
#38
Originally Posted by slender View Post
Hmmm. I can't believe that normal usage case (just from my hat) for indexing would occupy lots of resources. For first run surely, but if you put 5 documents and couple of songs daily. Instead lets say that you put 50 documents/emails daily and 100 songs then it could be problem.
True, but you've implicitly assumed a much more complicated application. Rather than run a periodic sweep that simply scans files for strings, you have to first see that something has been changed (for all applications, however they store their data), and then index these changes. Oh, and remove the old references.

Editing the a contact and fixing Fred's last name, as you had incorrectly typed Fluntstone when you meant Flintstone, means that you have to have a model of individual records inside the contacts database, and be able to track down and remove all the old references. The app may not edit in place after all, Fred's new record number could be 123599, with the old record at 12012 marked as simply marked as old. Otherwise the othe fields ("Note: wife's name Wilma") that weren't changed would turn up Fred's old record.
__________________
--
If you don't know who the Eletronic Frontier
Foundation are, you should. Check out
http://www.eff.org.
 

The Following User Says Thank You to Alan_Peery For This Useful Post:
Posts: 3,617 | Thanked: 2,412 times | Joined on Nov 2009 @ Cambridge, UK
#39
Originally Posted by Alan_Peery View Post
True, but you've implicitly assumed a much more complicated application. Rather than run a periodic sweep that simply scans files for strings, you have to first see that something has been changed (for all applications, however they store their data), and then index these changes. Oh, and remove the old references.
Finding that something's changed is pretty trivial - there's notification functionality built into the kernel (I think inotify is the current one, but it's been a while since I played with that).

Originally Posted by Alan_Peery View Post
Editing the a contact and fixing Fred's last name, as you had incorrectly typed Fluntstone when you meant Flintstone, means that you have to have a model of individual records inside the contacts database, and be able to track down and remove all the old references. The app may not edit in place after all, Fred's new record number could be 123599, with the old record at 12012 marked as simply marked as old. Otherwise the othe fields ("Note: wife's name Wilma") that weren't changed would turn up Fred's old record.
As you say, that's more complex, but is what you really ought to be doing anyway - simple string-based searching is going to fail for an awful lot of file formats (due to compression, binary formats, etc), so the indexer will need to know how to read the appropriate data from different file formats (for example, you can see that tracker already knows how to deal with ID3 tags in music files).
 

The Following User Says Thank You to Rob1n For This Useful Post:
Posts: 21 | Thanked: 13 times | Joined on Oct 2009
#40
well anyway, actual problem boils down to the root cause, why tracker has file contents functionality disabled. It worths creating a bug, so that to see if that is realistic feature to expect.
 
Reply


 
Forum Jump


All times are GMT. The time now is 12:14.