<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Yes. I think we came up with this a few days ago on IRC, and I would like to start hammering out details. I already have some code to index parcels, but right now all it does is output parcel changes to the console since there's no API or transport protocol to expose.<br><br>A simple exposed XML file polled at set intervals would be fine. But I would also like a way for a search service to subscribe to a sim's XML file to have it pushed (delta-compressed, of course) to the search service whenever something changes or at set intervals such that low-traffic sims get updated whenever something changes, but high-traffic sims don't flood the service with too many updates.<br><br>So I'll be back with an XML schema
 idea.<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Charles Krinke <cfk@pacbell.net><br>To: diva@metaverseink.com; opensim-dev@lists.berlios.de<br>Sent: Thursday, February 7, 2008 1:29:02 PM<br>Subject: Re: [Opensim-dev] OpenSim search<br><br>
<div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><div style="font-size: 12pt; font-family: arial,helvetica,sans-serif;">I'll weigh in here and say that I think Diva's thoughts appear sound to me and I would like to encourage them and offer a friendly environment to test them on OSGrid as they come together.</div>
<div style="font-size: 12pt; font-family: arial,helvetica,sans-serif;"> </div>
<div style="font-size: 12pt; font-family: arial,helvetica,sans-serif;">Charles<br><br></div>
<div style="font-size: 12pt; font-family: times new roman,new york,times,serif;">----- Original Message ----<br>From: Diva Canto <diva@metaverseink.com><br>To: opensim-dev@lists.berlios.de<br>Sent: Thursday, February 7, 2008 9:01:05 AM<br>Subject: [Opensim-dev] OpenSim search<br><br>Hi all,<br><br>I've been spending some time studying the project, to see how exactly I <br>can contribute towards enabling search engines in OpenSims/Grids. I have <br>a more concrete plan now that I'd like to share with you, and ask <br>whether this is something you think it's worth pursuing or not. If not, <br>then, well, never mind, it's just a plan! :-) If you think it's worth <br>pursuing, after getting your comments I will proceed to coding this <br>weekend, and when I'm done I'll submit my code as a patch for your <br>assessment and consideration. The patch involved in this is relatively <br>independent of everything that already exists, it would simply be
 <br>another server command that doesn't interfere with the existing ones. <br>Here's the details.<br><br>The very basic for a search engine to exist is the data that lives on <br>the sims. (I'll talk more about which data and data access control in <br>the next paragraph, but let's ignore that in this paragraph.) As such, <br>that data has to be exposed for collection. The right way to do this is <br>to generate an XML file representing the information on the sims, namely <br>parcel and object information. This file can then be served by the sim <br>via, for example, http. So, a possible interface to data collection <br>services might be as simple as this: <a rel="nofollow" target="_blank" href="http://tagus.ics.uci.edu/OpenSim">tagus.ics.uci.edu/OpenSim</a> Test.xml. <br>My concrete proposal as a first step is to implement a command that <br>generates this XML file, possibly called xml-snapshot.<br><br>Unlike the existing save/load commands, whose
 purpose is admin
 backups <br>and data ports, this external exposure doesn't need so many details and <br>must be aware of exposure controls.<br>- Less details: children prims in objects are irrelevant -- only the <br>root prims matter.<br>- Exposure control: the viewer's checkbox "Show in search" is a good <br>indicator of users intensions towards  external exposure. (In fact, that <br>button should really be called "Expose externally"). Only objects and <br>parcels that have that marked should be exposed.<br><br>Additionally to users intensions, there can be two more layers of <br>control, one at the sim admin level, and one at the grid admin level.<br>- At the sim level, each sim admin should have the power to override the <br>users checkboxes. Specifically, if sim admins decide that nothing in the <br>sim should be exposed then the xml-snapshot for those sims is a no-op.<br>- At the grid level, each grid operator should have the power to decide <br>whether to
 externally serve common assets, such as textures, or not. <br>More importanly, the grid operator should also be able to instruct the <br>sims on that grid that they should not serve the XML file to external <br>data collectors, only to data collectors that are "authorized" by the grid.<br><br>These controls enable a variety of grids, from very open to completely <br>closed, homogeneous, heterogeneous, and everything in between.<br>Once this external data exposure is in place, data collection components <br>(search engines and others) can do their thing.<br><br>Note that Linden Lab has recently moved from being a closed grid to <br>being open, with respect to sim and user data. Unfortunately, they <br>decided to use HTML as data representation...duh.<br><br>Additionally to the xml-snapshot command, I can volunteer to implement a <br>basic Lucene-based search engine that OpenSim grid operators can run on <br>their own grids. This is independent of any
 other search engines, and is <br>particularly useful in grids that are closed to the outside. The <br>argument here is that Lucene-based text search  is 100x better than <br>relational queries, under all aspects I can think of -- run-time <br>performance, sim/grid load, component coupling, and relevance of search <br>results.<br><br>Note that some parts of the search problem can still be served in the <br>traditional way. Specifically, user search seems like a really simple <br>thing to do with SQL, it's not like there are many Diva Canto's on the <br>grid... So the idea of a SQL-based search service for certain kinds of <br>data is not incompatible with what I'm proposing.<br><br>I'll wait for your comments, and, as I said, if you think this is not <br>worth pursuing, I'll go away :-)<br>Probably won't be able to reply until later tonight.<br><br>Diva<br><br><br>_______________________________________________<br>Opensim-dev mailing list<br><a
 rel="nofollow" ymailto="mailto:Opensim-dev@lists.berlios.de" target="_blank" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a rel="nofollow" target="_blank" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br></div>
<div style="font-size: 12pt; font-family: arial,helvetica,sans-serif;"><br></div></div><!-- kill --><div><br><br>-----Inline Attachment Follows-----<br><br>_______________________________________________<br>Opensim-dev 
mailing 
list<br><a ymailto="mailto:Opensim-dev@lists.berlios.de" 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><br></div></div><br>
      <hr size=1>Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile. <a href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ "> Try it now.</a></body></html>