hmm, what is the mantis issue for the idea of moving parcel data to a backend server? And what is the reason for this? <br><br>Personally I'm against moving even more things to a central server, having things local makes things much more flexible. Also if you have a distributed grid, with different people running different region servers, it makes everything so much easier.<br><br> What if a person wanted to implement some web based system for changing the parcels on their region. If it was all on a central server, it would be a much harder task. If its local then its just a matter of them writing that web application to access their local database. <br><br>I think really we should be trying to go in the other direction and seeing if we can move anything that is currently grid based to being more distributed. I'm so against the idea of everything being central. (unless there is no other way)<br><br><br><b><i>Sakai Openlife <sakai@openlifegrid.com></i></b>
wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> I think this search idea also re-inforces my earlier call (already in<br>Mantis) that parcel data should be held grid side. Rather than the current<br>position of in the local prim store. <br><br>However the option of it being local should still be there as not every<br>application of the OpenSimulator will be an 'SL Like' style Grid.<-Perhaps<br>flagged in the .ini<br><br>It may also be beneficial to have a 'parcel' just for handling this things<br>much like we have a grid server, as not to overwhelm existing services such<br>as GRID or USER.<br><br>Sakai Openlife<br><br>-----Original Message-----<br>From: opensim-dev-bounces@lists.berlios.de<br>[mailto:opensim-dev-bounces@lists.berlios.de] On Behalf Of<br>opensim-dev-request@lists.berlios.de<br>Sent: Monday, 4 February 2008 9:02 PM<br>To: opensim-dev@lists.berlios.de<br>Subject: Opensim-dev Digest,
Vol 6, Issue 5<br><br>Send Opensim-dev mailing list submissions to<br> opensim-dev@lists.berlios.de<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>or, via email, send a message with subject or body 'help' to<br> opensim-dev-request@lists.berlios.de<br><br>You can reach the person managing the list at<br> opensim-dev-owner@lists.berlios.de<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Opensim-dev digest..."<br><br><br>Today's Topics:<br><br> 1. Search server DB schema (David Wendt JR.)<br> 2. Re: Search server DB schema (Justin Clark-Casey)<br> 3. Re: Search server DB schema (Dalien Talbot)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 3 Feb 2008 10:19:35 -0800 (PST)<br>From: "David Wendt JR." <dcrkid@yahoo.com><br>Subject: [Opensim-dev] Search server DB schema<br>To:
Opensim-dev mailing list <opensim-dev@lists.berlios.de><br>Message-ID: <171180.25639.qm@web58314.mail.re3.yahoo.com><br>Content-Type: text/plain; charset="us-ascii"<br><br>Hello, OpenSim developers.<br><br> I have recently taken up OpenSim development. I'm writing plugins to<br>allow Search to work. I need your opinion on a database schema for storing<br>the indexed search information for a hypothetical (so far) new grid service<br>"SearchServer".<br><br> I figure out for searching "Places", "Popular Places", and "Land Sales"<br>we will need the following fields: Parcel UUID, Name, Description, LandArea,<br>Traffic, Region UUID, Region Maturity Flag, Region Parent Estate ID, Loc X,<br>Loc Y, Loc Z, Image UUID, ForSaleStatus, Category, ForSalePrice, AuctionID,<br>Owner UUID, OwnerIsGroup Flag. Some of these fields won't be implemented for<br>a long time (especially ParentEstates) but it's good to have those anyway.<br><br> The "Classifieds" search tab
requires these fields: Entry UUID, Name,<br>Description, Publisher UUID, Publisher Parent Estate ID, Image UUID,<br>ClassifiedPrice, AutoRenewFlag, Category, Region UUID, Loc X, Loc Y, Loc Z,<br>MatureFlag.<br><br> The "Events" calendar search tab requires these fields: Event UUID,<br>Name, Description, Publisher UUID, Publisher Parent Estate ID, Mature<br>Content Flag, Event Date, Event Length, Region UUID, Loc X, Loc Y, Loc Z,<br>Cover Charge. The Event calendar also supports notifying people who opt-in,<br>so it would also require another table with Event UUID and Subscribing<br>Avatar UUID.<br><br> New Search (which I don't forsee being able to implement until way<br>later) also requires sim object data. Object UUID, Parent Parcel UUID, Name,<br>ForSaleStatus, ForSalePrice, Loc X, Loc Y, Loc Z seem to be good enough.<br><br> Now I need your opinion on this schema. Is it a good idea to have each<br>type of searchable object in a separate table? Or would it be
more feasible<br>to have all the relevant fields in a single table "search" with an<br>"objecttype" enum to differentiate between the types?<br><br>From,<br> KMeist Hax<br><br><br><br><br> <br>____________________________________________________________________________<br>________<br>Be a better friend, newshound, and <br>know-it-all with Yahoo! Mobile. Try it now.<br>http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ <br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:<br>https://lists.berlios.de/pipermail/opensim-dev/attachments/20080203/15b30aed<br>/attachment-0001.html <br><br>------------------------------<br><br>Message: 2<br>Date: Mon, 04 Feb 2008 08:29:26 +0000<br>From: Justin Clark-Casey <jjustincc@googlemail.com><br>Subject: Re: [Opensim-dev] Search server DB schema<br>To: opensim-dev@lists.berlios.de<br>Message-ID: <47A6CCE6.4020205@googlemail.com><br>Content-Type: text/plain; charset=ISO-8859-1;
format=flowed<br><br>Hi David,<br><br>Personally, my instinct would be to have one table to hold all the <br>common fields between these searchable objects, and separate tables to <br>hold the details specific to each.<br><br>However, this opinion is formed more by my desire for neatness (not <br>having lots of redundant attributes for search objects where certain <br>fields don't apply) than any knowledge about how this may affect <br>performance.<br><br>Regards,<br><br>--<br>justincc<br><br>David Wendt JR. wrote:<br>> Hello, OpenSim developers.<br>><br>> I have recently taken up OpenSim development. I'm writing plugins <br>> to allow Search to work. I need your opinion on a database schema for <br>> storing the indexed search information for a hypothetical (so far) new <br>> grid service "SearchServer".<br>><br>> I figure out for searching "Places", "Popular Places", and "Land <br>> Sales" we will need the following fields: Parcel UUID,
Name, <br>> Description, LandArea, Traffic, Region UUID, Region Maturity Flag, <br>> Region Parent Estate ID, Loc X, Loc Y, Loc Z, Image UUID, <br>> ForSaleStatus, Category, ForSalePrice, AuctionID, Owner UUID, <br>> OwnerIsGroup Flag. Some of these fields won't be implemented for a <br>> long time (especially ParentEstates) but it's good to have those anyway.<br>><br>> The "Classifieds" search tab requires these fields: Entry UUID, <br>> Name, Description, Publisher UUID, Publisher Parent Estate ID, Image <br>> UUID, ClassifiedPrice, AutoRenewFlag, Category, Region UUID, Loc X, <br>> Loc Y, Loc Z, MatureFlag.<br>><br>> The "Events" calendar search tab requires these fields: Event <br>> UUID, Name, Description, Publisher UUID, Publisher Parent Estate ID, <br>> Mature Content Flag, Event Date, Event Length, Region UUID, Loc X, Loc <br>> Y, Loc Z, Cover Charge. The Event calendar also supports notifying <br>> people who
opt-in, so it would also require another table with Event <br>> UUID and Subscribing Avatar UUID.<br>><br>> New Search (which I don't forsee being able to implement until way <br>> later) also requires sim object data. Object UUID, Parent Parcel UUID, <br>> Name, ForSaleStatus, ForSalePrice, Loc X, Loc Y, Loc Z seem to be good <br>> enough.<br>><br>> Now I need your opinion on this schema. Is it a good idea to have <br>> each type of searchable object in a separate table? Or would it be <br>> more feasible to have all the relevant fields in a single table <br>> "search" with an "objecttype" enum to differentiate between the types?<br>><br>> From,<br>> KMeist Hax<br>><br>> ------------------------------------------------------------------------<br>> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try <br>> it now. <br>><br><http: us.rd.yahoo.com=""
evt="51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8<br">HDtDypao8Wcj9tAcJ%20> <br>><br>> ------------------------------------------------------------------------<br>><br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br><br><br>-- <br>justincc<br>Justin Clark-Casey<br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Mon, 4 Feb 2008 09:59:37 +0100<br>From: "Dalien Talbot" <dalienta@gmail.com><br>Subject: Re: [Opensim-dev] Search server DB schema<br>To: opensim-dev@lists.berlios.de<br>Message-ID:<br> <970c50810802040059p6d7389dav6b6dc6db80154f37@mail.gmail.com><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>David,<br><br>just curious - have you played with the non-relational methods of doing the<br>search ?<br><br>I've had a very good success with Xapian library - and it has
bindings for<br>anything and everything (although - yick. this would mean one more native<br>code lib in the code base).<br><br>But the upside is that it would allow for more flexible "google-like"<br>searches, imho - which is the very big plus. And you can allow quite a few<br>custom tags to be included into boolean search - even though it is not very<br>fast to index, the convenience of working with it was extremely pleasing.<br><br>Another interesting beast is sphinx - I did not test it personally, but from<br>what they write here:<br><br>http://www.mysqlperformanceblog.com/2007/07/23/sphinx-going-beyond-full-text<br>-search/<br><br>It looks quite promising scalability-wise.<br><br>An engine which was theoretically very good (at least according to the<br>benchmarks that I've read) was zettair. However, playing with the code<br>showed the quality of it is really "alpha" - sprinkled with assert's - and<br>not without a few bugs too :-) - so probably more of theoretical
interest.<br><br>/d<br><br><br><br><br>On Feb 3, 2008 7:19 PM, David Wendt JR. <dcrkid@yahoo.com> wrote:<br><br>> Hello, OpenSim developers.<br>><br>> I have recently taken up OpenSim development. I'm writing plugins to<br>> allow Search to work. I need your opinion on a database schema for storing<br>> the indexed search information for a hypothetical (so far) new grid<br>service<br>> "SearchServer".<br>><br>> I figure out for searching "Places", "Popular Places", and "Land<br>> Sales" we will need the following fields: Parcel UUID, Name, Description,<br>> LandArea, Traffic, Region UUID, Region Maturity Flag, Region Parent Estate<br>> ID, Loc X, Loc Y, Loc Z, Image UUID, ForSaleStatus, Category,<br>ForSalePrice,<br>> AuctionID, Owner UUID, OwnerIsGroup Flag. Some of these fields won't be<br>> implemented for a long time (especially ParentEstates) but it's good to<br>have<br>> those anyway.<br>><br>> The
"Classifieds" search tab requires these fields: Entry UUID, Name,<br>> Description, Publisher UUID, Publisher Parent Estate ID, Image UUID,<br>> ClassifiedPrice, AutoRenewFlag, Category, Region UUID, Loc X, Loc Y, Loc<br>Z,<br>> MatureFlag.<br>><br>> The "Events" calendar search tab requires these fields: Event UUID,<br>> Name, Description, Publisher UUID, Publisher Parent Estate ID, Mature<br>> Content Flag, Event Date, Event Length, Region UUID, Loc X, Loc Y, Loc Z,<br>> Cover Charge. The Event calendar also supports notifying people who<br>opt-in,<br>> so it would also require another table with Event UUID and Subscribing<br>> Avatar UUID.<br>><br>> New Search (which I don't forsee being able to implement until way<br>> later) also requires sim object data. Object UUID, Parent Parcel UUID,<br>Name,<br>> ForSaleStatus, ForSalePrice, Loc X, Loc Y, Loc Z seem to be good enough.<br>><br>> Now I need your opinion on
this schema. Is it a good idea to have each<br>> type of searchable object in a separate table? Or would it be more<br>feasible<br>> to have all the relevant fields in a single table "search" with an<br>> "objecttype" enum to differentiate between the types?<br>><br>> From,<br>> KMeist Hax<br>><br>> ------------------------------<br>> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it<br>><br>now.<http: us.rd.yahoo.com="" evt="51733/*http://mobile.yahoo.com/;_ylt=Ahu06i6<br">2sR8HDtDypao8Wcj9tAcJ><br>><br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>><br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:<br>https://lists.berlios.de/pipermail/opensim-dev/attachments/20080204/4c13fe39<br>/attachment-0001.html
<br><br>------------------------------<br><br>_______________________________________________<br>Opensim-dev mailing list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br><br><br>End of Opensim-dev Digest, Vol 6, Issue 5<br>*****************************************<br><br>_______________________________________________<br>Opensim-dev mailing list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></http:></dcrkid@yahoo.com></dalienta@gmail.com></http:></jjustincc@googlemail.com></opensim-dev@lists.berlios.de></dcrkid@yahoo.com></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.