This is in general, the same as my own thoughts in regards to search on opensim. In that we shouldn't be writing the search engines ourselves (although maybe including a basic one is a idea), but should include API's that various search engines can use to query the servers for data about the regions (parcel, prims, events etc). And yes having this in xml is I think the best. The only thing that maybe I would suggest, is that instead of doing one big xml for each region or each server, that we have a few API's, so that a query can be done for only a certain set of data (ie just for parcels or just for prims), but thats just a thought.  Diva Canto <diva@metaverseink.com> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Hi all, I've been spending some time studying the project, to see how exactly I  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: tagus.ics.uci.edu/OpenSim 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>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></blockquote><br><p> 

<hr size=1> Sent from <a href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=51949/*http://uk.docs.yahoo.com/mail/winter07.html">Yahoo!</a> - a smarter inbox.