LSL HTTP Server 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.
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.
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.
The answer to the problem is along the same lines as Toysholdier Thor’s excellent suggestion regarding virtual landmarks. Which is basically taking advantage of DNS to deliver results.
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.
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.
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.
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.
Personally I think LL should offer an internal database solution for a monthly recurring charge. This would take care of DNS issues along with a million other things that could be done with it. There are many of us spending a considerable amount of money outside SL for SQL hosting. It’s hard to believe LL would not want to tap into that revenue for something they have plenty of resources to handle.
I’ve suggested database hosting before, it’s something that plenty do, I could do what I want from an SQL database, i’ve tested it and it’s really efficient but I’m not so keen on the database being outside of SL, if LL gave me the option to have one on their servers, I’d almost certainly buy into it.
I’ve banged on about LL needing to investigate other income streams and in the case of database hosting, that’s really staring them in the face.
Indeed, you are right. And LL’s provided hosting would go along pretty well with my suggestion of web portals to groups as I suggested over a year ago in this post: http://indigomertel.posterous.com/linden-lab-has-the-best-social-tool-and-doesn
There are a number of additional services that the Lab could offer as part of a package for premium members. There have been several suggestions on this, it’s surprising that the Lab doesn’t take advantage of this opportunity.
I’m wholeheartedly in support of web portals for groups, it seems the sensible place to have group information and would be far more user friendly (if implemented correctly) than the current group system inworld with regards to information and notices, plus there’s lots more you can do on top of the current system if there’s a web version.
Indeed, a lot can be done by moving groups to the web: having mini forums (great for customers support), private forum sections for group staff, a neat presentation of the group and its news, even a repository for documents and files or a wiki.
Having such a system would greatly improve communication and promotion, on top of relieving groups chat from heavy load. And considering the thousands of special interest groups (furries, role-playing, historical, gaming, etc), opening groups to the web would be free promotion for SL.
This is a great suggestion, Ciaran. I think you should follow what Toysoldier did with virtual landmarks and forward your suggestion to the Lab. I’d be glad to support the initiative.
Carl Wilder created a Jira for this idea back in 2009, I’ve just searched the Jira:
https://jira.secondlife.com/browse/SVC-5114
Unfortunately we can no longer comment on Jira issues.
Toysoldier managed to get significant attention by posting his suggestion into one the SL forum and by advocating his idea inworld to user groups attended by the Lindens. Now, I know these things often are a “hit or miss” attempt, as is often the case when promoting anything in SL. But, I think this is worth a try, perhaps with the help of some prominent bloggers. I’d be glad to help if you decide to do it.
Ah, posting to the SLUniverse forum may help as well.