
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Verdana

}

</style>

</head>

<body class='hmmessage'>

Afaik the only region.xml data that depends on writing back is the map image asset id and last refresh. If they are not updated it will mean a re-creation on each region restart, wich is not that fatal, in some cases even desirable, I guess.<BR><BR>

Of course, them being stored in there I consider ugly hack. Should be part of the region data table, really.<BR>

<BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR> <BR><BR><BR>> Date: Fri, 12 Dec 2008 14:26:50 +0000<BR>> From: jjustincc@googlemail.com<BR>> To: opensim-dev@lists.berlios.de<BR>> Subject: Re: [Opensim-dev] external host name<BR>> <BR>> Kyle "G" wrote:<BR>> > Chris Hart has setup ReactionGrid to have region.xml files pulled form a <BR>> > web source already. She has greatly simplified our life by doing this <BR>> > and building some asp.net web admin tools for managing servers.<BR>> <BR>> That's rather interesting - I thought pulling region information from web was currently broken (because some other code <BR>> started trying to write information back to the 'file'). Is this no longer the case?<BR>> <BR>> > <BR>> > Kyle G<BR>> > <BR>> > www.reactiongrid.com <http://www.reactiongrid.com> <BR>> > <BR>> > <BR>> > <BR>> > *From:* opensim-dev-bounces@lists.berlios.de <BR>> > [mailto:opensim-dev-bounces@lists.berlios.de] *On Behalf Of *Stefan <BR>> > Andersson<BR>> > *Sent:* Friday, December 12, 2008 5:20 AM<BR>> > *To:* opensim-dev@lists.berlios.de<BR>> > *Subject:* Re: [Opensim-dev] external host name<BR>> > <BR>> > <BR>> > <BR>> > An often overlooked feature in OpenSim is to be able to pull Region.xml <BR>> > from a web source, and I believe the work needed to pull opensim.ini <BR>> > from a web source is minimal (maybe just some nini config magic?)<BR>> > <BR>> > In a setting where instances move around, this is probably features <BR>> > worth examining.<BR>> > <BR>> > Best regards,<BR>> > Stefan Andersson<BR>> > Tribal Media AB<BR>> > <BR>> > Join the 3d web revolution : http://tribalnet.se/<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > ------------------------------------------------------------------------<BR>> > <BR>> > <BR>> > Date: Thu, 11 Dec 2008 18:28:19 -0800<BR>> > From: dahliatrimble@gmail.com<BR>> > To: opensim-dev@lists.berlios.de<BR>> > Subject: Re: [Opensim-dev] external host name<BR>> > <BR>> > I think it may be beneficial to allow some kind of tag to be used in the <BR>> > region xml config file which may get the hostname or IP address from <BR>> > another source, perhaps an environment variable? I suggest this as I <BR>> > often move regions and their configs around to different hosts and it's <BR>> > a pain to keep changing the host name in the files. I guess a macro <BR>> > processor run on the file at region startup would accomplish the same <BR>> > thing, but it would be a convenience if opensim.exe did it.<BR>> > <BR>> > On Thu, Dec 11, 2008 at 6:11 PM, Teravus Ovares <teravus@gmail.com <BR>> > <mailto:teravus@gmail.com>> wrote:<BR>> > <BR>> > I agree. It is inconstant. On purpose. :). As I said, remoting<BR>> > issues caused regions in Linux and Windows to be unable to tell each<BR>> > other that they were online using the RegionInfo object.<BR>> > <BR>> > <BR>> > Best Regards<BR>> > <BR>> > Teravus<BR>> > <BR>> > On 12/11/08, Cristina Videira Lopes <lopes@ics.uci.edu <BR>> > <mailto:lopes@ics.uci.edu>> wrote:<BR>> >> The thing is that this can potentially create a RegionInfo data structure<BR>> >> with<BR>> >> nRegionInfo.ExternalHostName = regionData.IPADDR;<BR>> >><BR>> >> This is inconsistent with certain queries on the Grid server, like <BR>> > "give me<BR>> >> all my neighbors" which may send host names.<BR>> >><BR>> >> So, back to the point: someone needs to decide what is it that<BR>> >> RegionInfo.ExternalHostName is supposed to hold.<BR>> >><BR>> >><BR>> >> Teravus Ovares wrote:<BR>> >> RegionUpData is my fault, and spawned from compatibility issues with<BR>> > .NET<BR>> >> remoting and Mono remoting with complex types. It is only used<BR>> > to notify a<BR>> >> neighbor region that 'this region is up'<BR>> > <BR>> > Best Regards<BR>> > <BR>> > Teravus<BR>> > <BR>> > On<BR>> >> 12/11/08, Cristina Videira Lopes <lopes@ics.uci.edu <BR>> > <mailto:lopes@ics.uci.edu>> wrote:<BR>> > <BR>> >> Things are very messy right now. You can search for "sim_ip", for<BR>> >> example,<BR>> > which is used in chatting with the grid server, and where it is<BR>> >> being<BR>> > converted to an IP address in about half of the cases.<BR>> > <BR>> > To compensate,<BR>> >> and before I noticed this inconsistency, Homer introduced<BR>> > another field<BR>> >> called "sim_host", so not to mess with what was already there,<BR>> > that is<BR>> >> supposed to carry the external host name, but this only works up to<BR>> > the<BR>> >> point in which RegionInfo data structures are created. At that point,<BR>> >> we<BR>> > need to decide what to place in m_externalHostName, sim_ip or<BR>> >> sim_host.<BR>> > Which means changes in OGS1.<BR>> > <BR>> > I also noticed that there is yet<BR>> >> another data structure called RegionUpData<BR>> > that uses IP addresses.<BR>> > <BR>> > So,<BR>> >> messy. Someone should decide what this field is supposed to be, and make<BR>> > it<BR>> >> a rule.<BR>> > <BR>> > Charles Krinke wrote:<BR>> > <BR>> > Dear Diva:<BR>> > <BR>> > You have a very good point and I<BR>> >> would support harmonizing to one notion<BR>> > even at the expense of breaking some<BR>> >> things for a while.<BR>> > <BR>> > In fact, if someone can identify what some of those<BR>> >> things are, or come up<BR>> > with a couple of search strings or grep expressions,<BR>> >> I would like to look at<BR>> > the anomalies myself.<BR>> > <BR>> > +1 on<BR>> >> external_host_name<BR>> > <BR>> > Charles<BR>> > <BR>> > ________________________________<BR>> > <BR>> > <BR>> > From:<BR>> >> Cristina Videira Lopes <lopes@ics.uci.edu <mailto:lopes@ics.uci.edu>><BR>> > To:<BR>> >> opensim-dev@lists.berlios.de <mailto:opensim-dev@lists.berlios.de><BR>> > Sent: Thursday, December 11, 2008 2:42:05<BR>> >> PM<BR>> > Subject: [Opensim-dev] external host name<BR>> > <BR>> > It turns out that a lot of<BR>> >> problems with CAPs have to do with<BR>> > inconsistencies surrounding the URL of<BR>> >> the seed cap. Specifically, in<BR>> > some cases we're producing URLs with<BR>> >> hostnames, other times we're<BR>> > producing URLs with IP addresses, for<BR>> >> example:<BR>> > <BR>> > http://ucigrid03.nacs.uci.edu:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/<BR>> > vs.<BR>> > MailScanner<BR>> >> has detected a possible fraud attempt from "128.200.71.43:9000 <BR>> > <http://128.200.71.43:9000/>"<BR>> > claiming to<BR>> >> be MailScanner warning: numerical links are often malicious:<BR>> > MailScanner<BR>> >> warning: numerical links are often malicious:<BR>> >> http://128.200.71.43:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/<BR>> > <BR>> > The<BR>> >> client is not smart enough to test if this is the same host, it<BR>> > assumes it<BR>> >> isn't, so it decides someone's trying to game it.<BR>> > <BR>> > The inconsistencies are<BR>> >> all over the code in OpenSim, and they pertain<BR>> > to the use of<BR>> >> ExternalHostName in several data s! tructures. In some<BR>> > cases, an explicit<BR>> >> conversion to IP addresses is made.<BR>> > <BR>> > We should converge to one single thing.<BR>> >> And I believe that thing should<BR>> > be whatever it is given in<BR>> >> external_host_name config. Is this right?<BR>> > However, I am a bit afraid this is<BR>> >> going to break 17 different<BR>> >> things...<BR>> > <BR>> > Crista<BR>> > <BR>> > _______________________________________________<BR>> > Opensim-dev<BR>> >> mailing<BR>> >> list<BR>> > Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de><BR>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> > ________________________________<BR>> > <BR>> >> _______________________________________________<BR>> > Opensim-dev<BR>> >> mailing<BR>> > list<BR>> > <BR>> >> Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de><BR>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >> _______________________________________________<BR>> > Opensim-dev<BR>> >> mailing<BR>> >> list<BR>> > Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de><BR>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> > <BR>> > <BR>> >> _______________________________________________<BR>> > Opensim-dev<BR>> >> mailing<BR>> >> list<BR>> > Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de><BR>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >><BR>> >><BR>> >> _______________________________________________<BR>> >> Opensim-dev mailing list<BR>> >> Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de><BR>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >><BR>> >><BR>> > _______________________________________________<BR>> > Opensim-dev mailing list<BR>> > Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de><BR>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> > <BR>> > <BR>> > <BR>> > No virus found in this incoming message.<BR>> > Checked by AVG - http://www.avg.com<BR>> > Version: 8.0.176 / Virus Database: 270.9.16/1842 - Release Date: <BR>> > 12/11/2008 8:36 AM<BR>> > <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>> justincc<BR>> Justin Clark-Casey<BR>> http://justincc.wordpress.com<BR>> _______________________________________________<BR>> Opensim-dev mailing list<BR>> Opensim-dev@lists.berlios.de<BR>> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR><BR></body>

</html>