[Opensim-dev] OpenSim search

[Aldon Hynes]

I want to echo what I said a while ago about using XMPP

---
Another piece of functionality that would be very interesting would be to
expose search functionality via XMPP e.g.
  a.. JID: searchstring at userserver/searchtype
  b.. roster = search results
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.

Objects could also have their own JID
  a.. JID: UUID at userserver/object
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.
---

By making search available via XMPP, it would facilitate searches across
multiple grids.....

Aldon
  -----Original Message-----
  From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de]On Behalf Of Michael Wright
  Sent: Thursday, February 07, 2008 12:39 PM
  To: diva at metaverseink.com; opensim-dev at lists.berlios.de
  Subject: Re: [Opensim-dev] OpenSim search


  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 at metaverseink.com> wrote:
    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
    a more concrete plan now that I'd like to share with you, and ask
    whether this is something you think it's worth pursuing or not. If not,
    then, well, never mind, it's just a plan! :-) If you think it's worth
    pursuing, after getting your comments I will proceed to coding this
    weekend, and when I'm done I'll submit my code as a patch for your
    assessment and consideration. The patch involved in this is relatively
    independent of everything that already exists, it would simply be
    another server command that doesn't interfere with the existing ones.
    Here's the details.

    The very basic for a search engine to exist is the data that lives on
    the sims. (I'll talk more about which data and data access control in
    the next paragraph, but let's ignore that in this paragraph.) As such,
    that data has to be exposed for collection. The right way to do this is
    to generate an XML file representing the information on the sims, namely
    parcel and object information. This file can then be served by the sim
    via, for example, http. So, a possible interface to data collection
    services might be as simple as this: tagus.ics.uci.edu/OpenSim Test.xml.
    My concrete proposal as a first step is to implement a command that
    generates this XML file, possibly called xml-snapshot.

    Unlike the existing save/load commands, whose purpose is admin backups
    and data ports, this external exposure doesn't need so many details and
    must be aware of exposure controls.
    - Less details: children prims in objects are irrelevant -- only the
    root prims matter.
    - Exposure control: the viewer's checkbox "Show in search" is a good
    indicator of users intensions towards external exposure. (In fact, that
    button should really be called "Expose externally"). Only objects and
    parcels that have that marked should be exposed.

    Additionally to users intensions, there can be two more layers of
    control, one at the sim admin level, and one at the grid admin level.
    - At the sim level, each sim admin should have the power to override the
    users checkboxes. Specifically, if sim admins decide that nothing in the
    sim should be exposed then the xml-snapshot for those sims is a no-op.
    - At the grid level, each grid operator should have the power to decide
    whether to externally serve common assets, such as textures, or not.
    More importanly, the grid operator should also be able to instruct the
    sims on that grid that they should not serve the XML file to external
    data collectors, only to data collectors that are "authorized" by the
grid.

    These controls enable a variety of grids, from very open to completely
    closed, homogeneous, heterogeneous, and everything in between.
    Once this external data exposure is in place, data collection components
    (search engines and others) can do their thing.

    Note that Linden Lab has recently moved from being a closed grid to
    being open, with respect to sim and user data. Unfortunately, they
    decided to use HTML as data representation...duh.

    Additionally to the xml-snapshot command, I can volunteer to implement a
    basic Lucene-based search engine that OpenSim grid operators can run on
    their own grids. This is independent of any other search engines, and is
    particularly useful in grids that are closed to the outside. The
    argument here is that Lucene-based text search is 100x better than
    relational queries, under all aspects I can think of -- run-time
    performance, sim/grid load, component coupling, and relevance of search
    results.

    Note that some parts of the search problem can still be served in the
    traditional way. Specifically, user search seems like a really simple
    thing to do with SQL, it's not like there are many Diva Canto's on the
    grid... So the idea of a SQL-based search service for certain kinds of
    data is not incompatible with what I'm proposing.

    I'll wait for your comments, and, as I said, if you think this is not
    worth pursuing, I'll go away :-)
    Probably won't be able to reply until later tonight.

    Diva


    _______________________________________________
    Opensim-dev mailing list
    Opensim-dev at lists.berlios.de
    https://lists.berlios.de/mailman/listinfo/opensim-dev





----------------------------------------------------------------------------
--
  Sent from Yahoo! - a smarter inbox.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080207/0d5ed902/attachment-0001.html>