<br><br><div class="gmail_quote">On Feb 5, 2008 12:42 AM, Diva Canto <<a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I would hate that OpenSim follows Linden Lab's steps with search without<br>taking advantage of the lessons that even they already learned -- that<br>relational schemas are not appropriate for modern information retrieval.</blockquote>
<div><br>I soooo much want to print this sentence and hang it on the wall :-D<br><br>I did have an ambicious idea at one time to experiment with the SL search - and had pulled the info from userpicks of around 1 mln of the SL users, and pumped that into a mysql table... the queries from that table were not terribly fast (and yes, I did have an index  :-)<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>I'll be happy to help setting up this basic search service with Lucene,<br>
rather than with a relational DB. Lucene is, essentially, a highly<br>optimized database for text search. For example, issues like this<br><div class="Ih2E3d">" I'm going to assume name == varchar(63) and description ==<br>
varchar(127), but it might be easier to just set everything to<br>varchar(255) for flexibility."<br></div>are a non-problem in Lucene -- you can use as little or as much text as<br>you want in a field, you don't need to hard-code that.</blockquote>
<div><br>+1<br><br>There's an interesting paper:<br><br><a href="http://wrg.upf.edu/WRG/dctos/Middleton-Baeza.pdf">http://wrg.upf.edu/WRG/dctos/Middleton-Baeza.pdf</a><br><br>which outlines the performance/data volumes we should keep in mind - although something which seemed to be a winner on this analysis, zettair, have got me into a bigtime disappointment - the code is sprinkled by asserts, and there is at least one severe bug (database corruption when loading the cache) in there. the good news it is BSD licensed, so might be an interesting candidate :)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>Can I help with plugging a Lucene-based search for OpenSim, please? (the<br>
thought of having a relational DB serving text search makes me shiver :-)</blockquote><div><br>yes, please please :-)<br> <br>Although as David absolutely correctly points out, Lucene is GPL - so injecting it into the main BSD-licensed codebase is problematic.<br>
<br>So, we'd need to apply the license workaround and perform the linkage over TCP :-) (probably HTTP would be the least cumbersome choice)<br><br>given that all the items are always centered around some *place*, i think it might be logical to have the search completely grid-agnostic (although this does not prevent us in the future to push the "search server data" from UGA onto the sim, to avoid too much manual configuration)<br>
<br>Also, since potentially one might want to have their sim talk to more than one search engine, would be useful to keep this in mind<br><br>Bot-based crawl is useful - but assumes the flatness of the universe, which is true for SL - but is no longer true for opensim - at the moment there are a few parallel universes out there (deepgrid, osgrid, just to name a couple) - and there appears to be a demand on bringing those together.<br>
<br>So the things become bit more complicated :-) And i think it warrants the "push" mechanism for the regions to supply the contents to the search engines, rather than the "pull" mechanism that currently exists.<br>
<br>Another thing to keep in mind for the future - it would be nice to be able to talk to more than one search engine, while being on the sim (assuming we have the "multigrid" regions in the future.<br><br>ISo, to me it looks like there is a set of functions which would be characteristic to any search engine being used:<br>
<br>1) region registers the associated objects on it upon coming online<br><br>2) region notifies the search engine about it going offline. This can easily be a no-op for the beginning, but again useful to keep in mind.<br>
<br>3) region talks to the search engine to do the actual search and interprets its results depending on the type of search (assuming we do implement the "old-style" searches.)<br><br>4) region sends the add-update and delete requests to the search engine while running, as needed (this is similar to (1) and (2)), and could involve the stuff like updating the search rankings based onthe userpicks, or just objects being set for sale, etc.<br>
<br>In the tradition of modularization, it might make sense to abstract these functions into the region module "search", rather than snapping it directly atop the DB abstraction layer - since the freetext search engines and the DBs would have quite different interfaces, IMHO.<br>
<br>Then we might have additional region modules, which would know how to translate the above, into the engine-specific API (e.g.: database-search, lucene-search, etc.) <br><br>Those would register to the "search" module and take care of talking potentially to more than one search engine at once. The "search" module would dispatch the communication to the underlying backend-specific engines, and aggregate the search results (and return "nothing" in the case there are no backend-specific plugins loaded). <br>
<br>This approach in my opinion would avoid the lock-in into some specific search backend, and allow the relatively easy integration with enterprise search engines for those who have a desire to do so.<br><br>David - indeed, the os* functions would be a very good idea, and would interface to the same API as the (1,2,4) above.<br>
<br>(on a side note, an os* function to actually programmatically perform the search seems also like a good thing to have)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>I've never participated in an Open Source project as such, so I'm not<br>sure how the process is. </blockquote><div><br>"respectful anarchy", as Charles has noted the other day :-)<br><br>also, indeed, the IETF principle of "working implementations win" also holds true :-)<br>
<br>My suggestion to go with the regionmodule approach, is that it might be one of the most weakly coupled ways to do it - which is almost always a good thing :-)<br><br>Also - this would allow to accomodate the "low-dependency" approach of database search for local objects and for the case of standalone sim, as well as allow to have a lucene and what-not-else-based search for larger scale deployments.<br>
<br>One other reason why it is nice to start with both - they are so different, that making an abstraction that works for both, would allow to add the future search backends quite easily, IMHO. <br><br>What do you think of such an approach ?<br>
<br>Might be interesting to get together on IRC and discuss it further - what are your timezones ?<br><br>/d<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I did contribute to OS projects before --<br><a href="http://aspectj.org" target="_blank">aspectj.org</a>, co-founder, and more recently contributed plugins to XWiki<br>with one of my students.<br><br>Let me know.<br><br>
Crista Lopes / Diva Canto<br>School of Information and Computer Sciences<br>University of California, Irvine<br><div><div></div><div class="Wj3C7c"><br><br><br>_______________________________________________<br>Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>