On Fri, 2008-08-01 at 11:32 -0700, Lopatin, Alexander L wrote: > I got an impression that most of functionality you are looking could be > found in DLNA Open Source Projects > http://elinux.org/DLNA_Open_Source_Projects > > For example http://elisa.fluendo.com/ > > Thank you, > > Alex >
UPnP/DLNA is targeted for device-to-device architecture and it's communicated over TCP/UDP layers. I think we need a inter-process communication protocol like D-BUS is much more suitable because it doesn't have the overhead to run a whole UPnP stack just for notifications. Jimmy > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Rusty Lynch > Sent: Thursday, July 31, 2008 15:20 > To: Jimmy Huang > Cc: dev > Subject: Re: [Moblin Dev] Content Tagging/Searching on Moblin > > On Thu, 2008-07-31 at 14:23 -0700, Jimmy Huang wrote: > > On Thu, 2008-07-31 at 10:25 -0700, jketreno wrote: > > > Jimmy Huang wrote: > > > > On Wed, 2008-07-30 at 15:48 -0700, Rusty Lynch wrote: > > > >> Looking through the DBUS introspection at > > > >> > http://svn.gnome.org/svn/tracker/trunk/data/tracker-introspect.xml, I do > > > >> not see a mechanism for notification of new files? > > > >> > > > >> Is the expectation that the app has to re-initiate all of it's > searches > > > >> each time a new IndexingFinished signal is caught? > > > >> > > > >> For example... a photo app is viewing a UI displaying all photos > from > > > >> Christmas 2006 (i.e. search for all objects with Image:Date in a > given > > > >> range) that are tagged with "Family" and "Snow" (i.e. with > User:Keyword > > > >> containing "Family" or "Snow"), while at the same time some new > photo's > > > >> show up. > > > >> > > > >> It would be nice if there was some mechanism to have an > outstanding > > > >> query returning new results on new found data. > > > >> > > > > Tracker doesn't have a way to know "what files" are indexed, it > only > > > > knows "when" files are indexed. So yes, I would say that > application > > > > will need to call out a new search after each IndexFinished > signal. > > > > > > It would seem reasonable to extend the tracker API to accommodate > such > > > a mechanism. Pseudo code for such an API could be as follows: > > > > > > /* start a new search by creating a new search object with a > specific > > > * query. */ > > > ContentSearch *search = content_new_search(query) > > > > > > /* Configure the search to be continuous, and to send back > > > * notification of results every time_granularity milliseconds IFF > > > * the search has collected a hit within that time period */ > > > content_search_set_continuous(search, time_granularity) > > > > > > /* Hook up the callback for search results */ > > > g_signal_connect(search, "search_results_available", > > > search_results_available, search) > > > > > > /* Activate the search */ > > > content_search_execute(search); > > > > > > ... > > > > > > void search_results_available(..., ContentSearch *search) > > > { > > > GList *results = content_search_get_results(search); > > > GList *tmp = results; > > > while (tmp) { > > > printf("Result: %s\n", content_search_result_get_text( > > > CONTENT_SEARCH_RESULT(tmp->data))); > > > tmp = tmp->next; > > > } > > > ... > > > } > > > > > > The key concept is that the results should be provided asynchronous > > > and iteratively. In this way, a long running search that might take > a > > > second to complete could return partial results every 100 > milliseconds > > > as the search is processed allowing a much more dynamic and fluid > user > > > experience. > > > > > > The daemon can then manage long running searches; as new data is > added > > > to the system, the data can be passed through the search -- if it > > > matches, it gets added to the results pool and returned at the next > > > time interval. > > > > > > > This is a nice feature to have, although I do not think it exists in > > trackerd today. I'll post this in the mailing list and get feedback > on > > what the tracker community thinks. The project is quite active, and > it > > would be nice if Moblin can bring in some influence toward their > > development directions to fill in some of the gaps we have. > > If we end up heavily depending on Tracker then you will definitely need > to become an active member of that development community. > > I haven't worked with this specific community, but I would bet showing > up with some proof-of-concept type of patch would go a long ways in > explaining what you need. > > I was quickly looking through the Sqlite3 interfaces and I do not see a > native mechanism to do this (i.e. as soon as you pull out the last row > of data and get an SQL_DONE, then the database VM needs to be reset.) > But... it seems like you could build a new query that limits the results > to only items that have been added since the last search, and then that > query and call the callback with the new rows of data. > > A little experimenting with help flush out the idea (or prove it to be > total rubbish.) > > --rusty > > _______________________________________________ > dev mailing list > [email protected] > https://www.moblin.org/mailman/listinfo/dev _______________________________________________ dev mailing list [email protected] https://www.moblin.org/mailman/listinfo/dev
