<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=703312817-07022008>I want
to echo what I said a while ago about using XMPP</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=703312817-07022008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=703312817-07022008>---</SPAN></FONT></DIV>
<DIV><SPAN class=703312817-07022008>
<DIV><SPAN class=765081413-28012008><FONT face=Arial color=#0000ff
size=2>Another piece of functionality that would be very interesting would be to
expose search functionality via XMPP e.g.</FONT></SPAN></DIV>
<UL>
<LI><SPAN class=765081413-28012008><FONT face=Arial color=#0000ff size=2>JID:
</FONT><A href="mailto:searchstring@userserver/searchtype"><FONT face=Arial
size=2>searchstring@userserver/searchtype</FONT></A></SPAN><FONT face=Arial
color=#0000ff size=2> </FONT>
<LI><SPAN class=765081413-28012008><FONT face=Arial color=#0000ff
size=2>roster = search results</FONT></SPAN></LI></UL>
<DIV><SPAN class=765081413-28012008><FONT face=Arial color=#0000ff size=2>The
search type could be optional. If it is omitted, it would imply all.
It could be people or places returning the user JIDs as the roster, as decribed
above for people searches or the location JIDs as described above for places (or
popularplaces) searches. For all, it could return a mix of both people and
locations.</FONT></SPAN></DIV>
<DIV><SPAN class=765081413-28012008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=765081413-28012008><FONT face=Arial color=#0000ff
size=2>Objects could also have their own JID</FONT></SPAN></DIV>
<UL>
<LI>
<DIV align=left><SPAN class=765081413-28012008><FONT face=Arial color=#0000ff
size=2>JID: </FONT><A href="mailto:UUID@userserver/object"><FONT face=Arial
size=2>UUID@userserver/object</FONT></A></SPAN></DIV></LI></UL>
<DIV><SPAN class=765081413-28012008><FONT face=Arial color=#0000ff size=2>For
people, this could provide an alternative way of contacting the person, but
mostly, it would be direct communications with an object. I'm not sure
what an object should return as its roster.</FONT></SPAN></DIV>
<DIV><SPAN class=765081413-28012008><SPAN class=703312817-07022008><FONT
face=Arial color=#0000ff size=2>---</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=765081413-28012008><SPAN class=703312817-07022008><FONT
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN> </DIV>
<DIV><SPAN class=765081413-28012008><SPAN class=703312817-07022008><FONT
face=Arial color=#0000ff size=2>By making search available via XMPP, it would
facilitate searches across multiple grids.....</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=765081413-28012008><SPAN class=703312817-07022008><FONT
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN> </DIV>
<DIV><SPAN class=765081413-28012008><SPAN class=703312817-07022008><FONT
face=Arial color=#0000ff size=2>Aldon</FONT></SPAN></SPAN></DIV></SPAN></DIV>
<BLOCKQUOTE>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B>
opensim-dev-bounces@lists.berlios.de
[mailto:opensim-dev-bounces@lists.berlios.de]<B>On Behalf Of </B>Michael
Wright<BR><B>Sent:</B> Thursday, February 07, 2008 12:39 PM<BR><B>To:</B>
diva@metaverseink.com; opensim-dev@lists.berlios.de<BR><B>Subject:</B> Re:
[Opensim-dev] OpenSim search<BR><BR></FONT></DIV>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).<BR><BR>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.
<BR><BR><B><I>Diva Canto <diva@metaverseink.com></I></B> wrote:
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(16,16,255) 2px solid">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: 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.</BLOCKQUOTE></BODY></HTML>