<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-GB link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>It’s a one-way pull on startup with no writing back if you use
web regions – I did have a dig around to see if I could figure out a way to
enable that somehow, but it seemed like a lot of effort for not a lot of gain.
What I would like to see is a fall-back – if web regions load fails, go back
and try the filesystem. It’s on my todo list – depends on whether others think
this would be useful as to how soon I get round to it.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Chris <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> opensim-dev-bounces@lists.berlios.de
[mailto:opensim-dev-bounces@lists.berlios.de] <b>On Behalf Of </b>Stefan
Andersson<br>
<b>Sent:</b> 12 December 2008 14:32<br>
<b>To:</b> opensim-dev@lists.berlios.de<br>
<b>Subject:</b> Re: [Opensim-dev] external host name<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>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<o:p></o:p></span></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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/1841 - Release Date: 11/12/2008
20:58</span><o:p></o:p></p>
</div>
</body>
</html>