{"id":2186,"date":"2012-10-28T20:55:38","date_gmt":"2012-10-28T20:55:38","guid":{"rendered":"http:\/\/sl.governormarley.com\/?p=2186"},"modified":"2012-10-28T20:59:45","modified_gmt":"2012-10-28T20:59:45","slug":"internal-lsl-http-servers-could-do-with-dns","status":"publish","type":"post","link":"https:\/\/sl.governormarley.com\/?p=2186","title":{"rendered":"Internal LSL HTTP Servers Could Do With DNS"},"content":{"rendered":"

LSL HTTP Server<\/a> is a lovely concept, unfortunately it has drawbacks. This works great when you want information from external servers, but it’s a pain when you want information from inworld objects. I’ve been working on making a notecard giver that you update centrally and it updates your remote boards, HTTP is a great way of doing this, the only problem is, URL’s are temporary.<\/p>\n

What we really need is for these addresses to take advantage of DNS for simple tasks, so instead of the address being an IP address, it is something along the lines of http:\/\/www.secondlife.com\/region_name\/objectAddress. This is why DNS is such a great concept.<\/p>\n

Currently I have to use a system of updating my remote boards using llEmail to inform them of the new URL. This means that I need to store the extenal objects email addresses and use llEmail to update them, this is not only cumbersome, it’s a waste of resouces as I have to communicate with a system that Linden Lab themselves recognises as having serious bottleneck issues.<\/p>\n

<\/p>\n

The answer to the problem is along the same lines as Toysholdier Thor’s excellent suggestion regarding virtual landmarks<\/a>. Which is basically taking advantage of DNS to deliver results.<\/p>\n

We really shouldn’t need to go to addresses outside of Second Life to take advantage of efficient HTTP communications. Now there would be issues, Linden Lab would not want to have people constanly changing addresses so maybe it should be that you are allowed a pool of addresses determined upon your land holdings or you are allowed x amount of DNS names based upon being a premium or concierge customer.<\/p>\n

However, it seems silly to have to use external databases to perform tasks that not only make communications more efficient, they also take load off a sim. Currently we use workarounds to detect when a URL has changed, but this means we need to use more resources than is ideal to update remote objects.<\/p>\n

My, admittedly limited testing, has shown to me that http communications within Second Life are both robust and efficient. However I’m wary of using something that relies on http communications and llEmail, when I can do everything with llEmail anyway. llEmail has bottlenecks, but as I’m using it anyway, it makes my use of http on top of it, a little redundant.<\/p>\n

There are other ways of keeping URL’s, but they all involve more work than is ideal, for simple tasks, and a centrally managed notecard giver is a simple task, it would be better all around if we didn’t need to use workarounds. Obviously, if this were straight forward for Linden Lab to deliver, it would already be here, so there are reasons why it’s not, but it would be a nice to have. Not having this functionality, isn’t the end of the world, but it would aid efficency.<\/p>\n

Tweet<\/a>
\n