<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-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">SearchServer will already cache the sim parcel and object data in a central database which gets updated by the sims.</DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR> </DIV>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: Sakai Openlife <sakai@openlifegrid.com><BR>To: opensim-dev@lists.berlios.de<BR>Sent: Monday, February 4, 2008 11:24:16 AM<BR>Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 6, Issue 7<BR><BR>Parcel data to a common database rather than local could allow easy exposure<BR>to web via MySQL/MSSQL for easy publish. Along with control via a portal<BR>etc. This can have applications such as an Educational inhouse grid or an<BR>intranet grid or even an SL Like styled Grid. <BR>Note I did mention the "option" in the .ini it doesn;'t 'have' to only be<BR>there.<BR><BR>Else do you propose a different method to mine the information about parcel<BR>data for search etc? I would be having an simple stab here that it would be<BR>easiest to grab it off one DB initially. I'm simply suggesting there are<BR>some quick applications for such usage

 immediately if it were in 1 DB to<BR>start.<BR><BR>Sakai Openlife<BR><BR><BR><BR><BR>-----Original Message-----<BR>From: <A href="mailto:opensim-dev-bounces@lists.berlios.de" ymailto="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</A><BR>[mailto:<A href="mailto:opensim-dev-bounces@lists.berlios.de" ymailto="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</A>] On Behalf Of<BR><A href="mailto:opensim-dev-request@lists.berlios.de" ymailto="mailto:opensim-dev-request@lists.berlios.de">opensim-dev-request@lists.berlios.de</A><BR>Sent: Tuesday, 5 February 2008 2:04 AM<BR>To: <A href="mailto:opensim-dev@lists.berlios.de" ymailto="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</A><BR>Subject: Opensim-dev Digest, Vol 6, Issue 7<BR><BR>Send Opensim-dev mailing list submissions to<BR>    <A href="mailto:opensim-dev@lists.berlios.de"

 ymailto="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</A><BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR>    <A href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target=_blank>https://lists.berlios.de/mailman/listinfo/opensim-dev</A><BR>or, via email, send a message with subject or body 'help' to<BR>    <A href="mailto:opensim-dev-request@lists.berlios.de" ymailto="mailto:opensim-dev-request@lists.berlios.de">opensim-dev-request@lists.berlios.de</A><BR><BR>You can reach the person managing the list at<BR>    <A href="mailto:opensim-dev-owner@lists.berlios.de" ymailto="mailto:opensim-dev-owner@lists.berlios.de">opensim-dev-owner@lists.berlios.de</A><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. Re: Opensim-dev Digest, Vol 6, Issue 5 (Dr

 Scofield)<BR>  2. search server Re:  Opensim-dev Digest, Vol 6, Issue 5<BR>      (Dalien Talbot)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 1<BR>Date: Mon, 04 Feb 2008 14:44:41 +0100<BR>From: Dr Scofield <<A href="mailto:hud@zurich.ibm.com" ymailto="mailto:hud@zurich.ibm.com">hud@zurich.ibm.com</A>><BR>Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 6, Issue 5<BR>To: <A href="mailto:opensim-dev@lists.berlios.de" ymailto="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</A><BR>Message-ID: <<A href="mailto:47A716C9.9050602@zurich.ibm.com" ymailto="mailto:47A716C9.9050602@zurich.ibm.com">47A716C9.9050602@zurich.ibm.com</A>><BR>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR><BR>Michael Wright wrote:<BR>> hmm, what is the mantis issue for the idea of moving parcel data to a <BR>> backend server? And what is the reason for

 this?<BR>><BR>> Personally I'm against moving even more things to a central server, <BR>> having things local makes things much more flexible. Also if you have <BR>> a distributed grid, with different people running different region <BR>> servers, it makes everything so much easier.<BR>><BR>>  What if a person wanted to implement some web based system for <BR>> changing the parcels on their region. If it was all on a central <BR>> server, it would be a much harder task. If its local then its just a <BR>> matter of them writing that web application to access their local <BR>> database.<BR>><BR>> I think really we should be trying to go in the other direction and <BR>> seeing if we can move anything that is currently grid based to being <BR>> more distributed. I'm so against the idea of everything being central. <BR>> (unless there is no other way)<BR>quite agree. ideally, we would be able to add

 "region links" to <BR>standalone grids, instead of running in "grid mode". yes, a region link <BR>would be more than just a link to another region, it would have to <BR>include information about remote asset server, agent server, etc. then <BR>there's the question of geography/topology...<BR><BR>    cheers<BR>    dr scofield<BR><BR>-- <BR>dr dirk husemann, pervasive computing, ibm zurich research lab<BR>--- <A href="mailto:hud@zurich.ibm.com" ymailto="mailto:hud@zurich.ibm.com">hud@zurich.ibm.com</A> --- +41 44 724 8573 --- SL: dr scofield<BR><BR><BR><BR>------------------------------<BR><BR>Message: 2<BR>Date: Mon, 4 Feb 2008 17:02:42 +0100<BR>From: "Dalien Talbot" <<A href="mailto:dalienta@gmail.com" ymailto="mailto:dalienta@gmail.com">dalienta@gmail.com</A>><BR>Subject: [Opensim-dev] search server Re:  Opensim-dev Digest, Vol 6,<BR>    Issue 5<BR>To: <A href="mailto:opensim-dev@lists.berlios.de"

ymailto="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</A> Message-ID:     <<A href="mailto:970c50810802040802j77923cb6h1b47effb0afb3725@mail.gmail.com" ymailto="mailto:970c50810802040802j77923cb6h1b47effb0afb3725@mail.gmail.com">970c50810802040802j77923cb6h1b47effb0afb3725@mail.gmail.com</A>> Content-Type: text/plain; charset="iso-8859-1" On Feb 4, 2008 12:08 PM, Sakai Openlife <<A href="mailto:sakai@openlifegrid.com" ymailto="mailto:sakai@openlifegrid.com">sakai@openlifegrid.com</A>> wrote: > I think this search idea also re-inforces my earlier call (already in > Mantis) that parcel data should be held grid side. Rather than the current > position of in the local prim store. > in other words you are suggesting all the websites should hold their data in google cache as their  primary content repository ? how does yahoo get the content then ?

 we don't want monopolies :-)<BR><BR>indeed the search servers can and should have a *secondary* copy of the<BR>information.<BR><BR>But making them hold the *primary* copy IMHO  makes that yet another<BR>bottleneck and maintenance load, alongside with the UGA.<BR><BR>I'm talking about a server to hold a few dozen millions of records and<BR>~10-100 requests per second<BR><BR>/d<BR><BR><BR><BR><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<BR>> such<BR>> as GRID or USER.<BR>><BR>> Sakai Openlife<BR>><BR>> -----Original Message-----<BR>> From: <A href="mailto:opensim-dev-bounces@lists.berlios.de"

 ymailto="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</A><BR>> [mailto:<A href="mailto:opensim-dev-bounces@lists.berlios.de" ymailto="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</A>] On Behalf Of<BR>> <A href="mailto:opensim-dev-request@lists.berlios.de" ymailto="mailto:opensim-dev-request@lists.berlios.de">opensim-dev-request@lists.berlios.de</A><BR>> Sent: Monday, 4 February 2008 9:02 PM<BR>> To: <A href="mailto:opensim-dev@lists.berlios.de" ymailto="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</A><BR>> Subject: Opensim-dev Digest, Vol 6, Issue 5<BR>><BR>> Send Opensim-dev mailing list submissions to<BR>>        <A href="mailto:opensim-dev@lists.berlios.de" ymailto="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</A><BR>><BR>> To subscribe or unsubscribe via the World Wide Web,

 visit<BR>>        <A href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target=_blank>https://lists.berlios.de/mailman/listinfo/opensim-dev</A><BR>> or, via email, send a message with subject or body 'help' to<BR>>        <A href="mailto:opensim-dev-request@lists.berlios.de" ymailto="mailto:opensim-dev-request@lists.berlios.de">opensim-dev-request@lists.berlios.de</A><BR>><BR>> You can reach the person managing the list at<BR>>        <A href="mailto:opensim-dev-owner@lists.berlios.de" ymailto="mailto:opensim-dev-owner@lists.berlios.de">opensim-dev-owner@lists.berlios.de</A><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." <<A href="mailto:dcrkid@yahoo.com" ymailto="mailto:dcrkid@yahoo.com">dcrkid@yahoo.com</A>><BR>> Subject: [Opensim-dev] Search server DB schema<BR>> To: Opensim-dev mailing list <<A href="mailto:opensim-dev@lists.berlios.de" ymailto="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</A>><BR>> Message-ID: <<A href="mailto:171180.25639.qm@web58314.mail.re3.yahoo.com" ymailto="mailto:171180.25639.qm@web58314.mail.re3.yahoo.com">171180.25639.qm@web58314.mail.re3.yahoo.com</A>><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<BR>> 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,<BR>> LandArea,<BR>> Traffic, Region UUID, Region Maturity Flag, Region Parent Estate ID, Loc<BR>> X,<BR>> Loc Y, Loc Z, Image UUID, ForSaleStatus, Category, ForSalePrice,<BR>> AuctionID,<BR>> Owner UUID, OwnerIsGroup Flag. Some of these fields won't be implemented<BR>> 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<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>><BR>><BR>><BR>><BR>><BR>____________________________________________________________________________<BR>> ________<BR>> Be a better friend, newshound, and<BR>> know-it-all with Yahoo! Mobile.  Try it now.<BR>> <A href="http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ" target=_blank>http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ</A><BR>> -------------- next part --------------<BR>> An HTML attachment was scrubbed...<BR>> URL:<BR>><BR>><BR><A href="https://lists.berlios.de/pipermail/opensim-dev/attachments/20080203/15b30aed"

 target=_blank>https://lists.berlios.de/pipermail/opensim-dev/attachments/20080203/15b30aed</A><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 <<A href="mailto:jjustincc@googlemail.com" ymailto="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</A>><BR>> Subject: Re: [Opensim-dev] Search server DB schema<BR>> To: <A href="mailto:opensim-dev@lists.berlios.de" ymailto="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</A><BR>> Message-ID: <<A href="mailto:47A6CCE6.4020205@googlemail.com" ymailto="mailto:47A6CCE6.4020205@googlemail.com">47A6CCE6.4020205@googlemail.com</A>><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>> <<BR>><BR><A href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8" target=_blank>http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8</A><BR>> HDtDypao8Wcj9tAcJ%20><BR>> ><BR>> > ------------------------------------------------------------------------<BR>> ><BR>> > _______________________________________________<BR>> > Opensim-dev mailing list<BR>> > <A href="mailto:Opensim-dev@lists.berlios.de" ymailto="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>> ><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" <<A href="mailto:dalienta@gmail.com" ymailto="mailto:dalienta@gmail.com">dalienta@gmail.com</A>><BR>> Subject: Re: [Opensim-dev] Search server DB schema<BR>> To: <A href="mailto:opensim-dev@lists.berlios.de" ymailto="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</A><BR>> Message-ID:<BR>>        <<A href="mailto:970c50810802040059p6d7389dav6b6dc6db80154f37@mail.gmail.com" ymailto="mailto:970c50810802040059p6d7389dav6b6dc6db80154f37@mail.gmail.com">970c50810802040059p6d7389dav6b6dc6db80154f37@mail.gmail.com</A>><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<BR>>

 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<BR>> 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<BR>> from<BR>> what they write here:<BR>><BR>><BR>><BR><A href="http://www.mysqlperformanceblog.com/2007/07/23/sphinx-going-beyond-full-text" target=_blank>http://www.mysqlperformanceblog.com/2007/07/23/sphinx-going-beyond-full-text</A><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<BR>>  interest.<BR>><BR>> /d<BR>><BR>><BR>><BR>><BR>> On Feb 3, 2008 7:19 PM, David Wendt JR. <<A href="mailto:dcrkid@yahoo.com" ymailto="mailto:dcrkid@yahoo.com">dcrkid@yahoo.com</A>> 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<BR>> 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,<BR>> Description,<BR>> > LandArea, Traffic, Region UUID, Region Maturity Flag, Region Parent<BR>> 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,<BR>> 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<BR>> 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<BR>> 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<BR>> it<BR>> ><BR>> now.<<BR>> <A href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i6" target=_blank>http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i6</A><BR>> 2sR8HDtDypao8Wcj9tAcJ><BR>> ><BR>> > _______________________________________________<BR>> > Opensim-dev mailing list<BR>> > <A href="mailto:Opensim-dev@lists.berlios.de" ymailto="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>> ><BR>> ><BR>> -------------- next part --------------<BR>> An HTML attachment was scrubbed...<BR>> URL:<BR>><BR>><BR><A href="https://lists.berlios.de/pipermail/opensim-dev/attachments/20080204/4c13fe39" target=_blank>https://lists.berlios.de/pipermail/opensim-dev/attachments/20080204/4c13fe39</A><BR>> /attachment-0001.html<BR>><BR>> ------------------------------<BR>><BR>> _______________________________________________<BR>> Opensim-dev mailing list<BR>> <A href="mailto:Opensim-dev@lists.berlios.de" ymailto="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>><BR>><BR>> End of Opensim-dev Digest, Vol 6, Issue 5<BR>>

 *****************************************<BR>><BR>> _______________________________________________<BR>> Opensim-dev mailing list<BR>> <A href="mailto:Opensim-dev@lists.berlios.de" ymailto="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>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL:<BR><A href="https://lists.berlios.de/pipermail/opensim-dev/attachments/20080204/8779905b" target=_blank>https://lists.berlios.de/pipermail/opensim-dev/attachments/20080204/8779905b</A><BR>/attachment.html <BR><BR>------------------------------<BR><BR>_______________________________________________<BR>Opensim-dev mailing list<BR><A href="mailto:Opensim-dev@lists.berlios.de"

 ymailto="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><BR><BR>End of Opensim-dev Digest, Vol 6, Issue 7<BR>*****************************************<BR><BR>_______________________________________________<BR>Opensim-dev mailing list<BR><A href="mailto:Opensim-dev@lists.berlios.de" ymailto="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 style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><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>