A new Communications Systm from SL to RL and back...

So, a partner and I are thinking about setting up what we are calling an SL Satelite System ( CommSatSL ) for object communication from in world, out to an enterprise level messaging system in RL and back. Now, we've worked out most of the tech details and have done some testing of a small proto type system and the big question is, is this something people need or want.

The genesis of the idea came from our need for fast, reliable, large capacity, and secure communications with outside servers, that has little to no LL built in delay, and little to no lag. We have been looking at SL and developing a couple of games as a way to see how the economy works and the soundness of the technical infrastructure, with the intention of moving to full mainstream ecommerce development once we got a lay of the land.

Well, it's been a year now, and having finished our two main games (See the VOLCANO game and the Magic Mushroom game), and we have learned quite a bit.

Having experienced that development; we've concluded that to take SL from it's equivalent to the "Brochure-ware" days of the internet to the "eCommerse" era, a more robust communications layer is required.

XML-RPC would have been our first choice due to the realability that messaging technologies offer through their "guaranteed delivery" aspects. (as illustrated by the fact that all of SL runs on top of a messaging platform) But we all know what is to become of XML-RPC.

Then there is http. The lag suseptable, built-in delay, limitted size and quantity, unreliable communications layer. It is the official avenue for communication from inside SL out to the real world. But in addition to the problems mentioned, you can't push messages in world without first polling from inside. Not acceptable.

Well, correct me if I'm wrong but that's about it, oh wait and there is email with it's automatic 20 second delays going out, total reliance on the often overloaded outside LL email servers and built in traffic limits. Not fast or reliable enough for serious business.

Anyway, we are hoping to offer a subscription based (think website hosting type accounting of bandwidth and size allocations) communications alternative, that will offer fast and reliable delivery with no built in delay and minimal to no lag production connected to an RL based, enterprise level, messaging solution, that will queue all messages for delivery to and from subscribing clients within their own queues.

Well, thats the deal. What do you all think? Worth pursuing? Would this be of any use to any of you? Let me know what you think? Brutal responses may receive rebuttal but not flames....h.

I don't get it. Your system has to run through one of those three layers, XML-RPC, HTTP, or email. They all fairly suck. HTTP, being the prime system, would only be able to achieve any form of realistic two-way communication through some sort of polling system. I fail to see how this, still stuck under the limits of requests right now, could meet the ideal of 'fast, reliable, no built in delay, and minimal to no lag production.' But if you want to debunk my cries of shenanigans, be my guest, because the service itself would be welcome. I wouldn't be willing to pay for it myself though, because I have no need serious enough for realtime communications, and because it would need to prove itself reliable for a good while first.

Edit: You could probably sell your system on the idea of reliability and message queuing provided that it is actually stable, but this still relies on polling requests, which is very sub-optimal.

seems I remember something about quicktime being used to push animations to prims... or was that a weird dream? I could certainly see possibilities there

yes I can see people wanting more useful and fast communications through SL, all dependant on what features would be available, and what your target crowd is... corporate is your best bet, and depending on integration possibilites your average user might be second... at a guess there aren't many early adopters in the SL content vendors crowd (unsubstantiated opinion)

The idea of scripts being able to perform as http_server has been proposed by one Linden to replace xml-rpc. This would get rid of the need to do constant polling. While no work has been done to implement it, I would be highly surprised if this ability didn't pop up in the next few months:

http://jira.secondlife.com/browse/SVC-913

I think, I wouldn't pay for such a service - not even for commercial purposes. This is _really_ something I expect to be built in SL - and as Jesse's post states, we might be closer to a really nice solution.
If they add the ability to transfer textures to this, that'd be really cool...

But I worry that, like XML-RPC and HTTP, what ever new protocol they develop ends up having to be offered universally, meaning, you are competing with everyone in that SIM using it for every reason in the book. The load on these resources (especially in busy sims) ends up being every man for himself. So you end up suffering for the guy next to you that has his timer set to poll for whatever every .02 seconds because of his inexperience in scripting or just down right greedness.

In my experience with our game development, we originally wrote a very http intensive communications layer until we ran into performance limitations in busy venues and in general. As much as we require communications resources I also don't want to be the reason all other script around me can't communicate effectively. Thats just being a jerk. With our new system a subscriber could share a connection with others or if it is important to their app can get a private connection that gives them maximum priority and does not impact others around him.

I freely admit our solution is not for your low-end vendor kiosk, or visitors log. Http handles that stuff fine. It's all about the criticality of your app. If you are Amazon or GM and have setup a real presence in SL, you don't want to compete with the thousand little "Bling" apps that some scripter decided would check the server every few seconds to know how "Blingy" it should be. In the case of our games, communication is vital to the operation of our game and I would be willing to pay for the priority.

From the JIRA and Kelly Linden:

<QUOTE>
To be extra crystal clear: This is a design proposal and suggestion. It is not a linden-sanctioned-official-feature. No one is currently implementing this, and no ETA for even when development on this or any similar feature might start.
</QUOTE>

My rebuttal...just one mans veiwpoint.

Well - I see your point, hiro. Although, I think if the Lindens _really_ want to attract business to SL, they somehow have to come up with either a similar solution like yours (which would most likely lead to the same discussion as the ongoing «net neutrality»-issue), or they have to implement something that works for everybody. One solution might be, that such communication wouldn't be routed through SL's servers, but, like QT for example, would be drawn directly from the client (just a thought).

And working business is somehow crucial to SL. So the sooner or later they simply _have_ to do something or it'll die (or never take off the way it _could_)...

What's even more important, I don't like to be «hooked» to some 3rd party service in SL. We recently had some problems with our stream-provider. In the beginning, everything looked fine and quite professional, but it turned out that the guy wasn't really able to provide a steady service - and we were screwed. I don't wanna say I don't trust you but you might also go out of business (for _whatever_ reason) and then all my communication would stop? Frankly, too much risk. Thus being said - I rather have a not-so-fast service provided by the Lindens and cope with the problems this service has. When SL dies, the party's over anyway - if just your service dies, I still have a running business that'll be screwed...

The «problem» with SL is - there are as many ideas and possibilities as there are users. Question is, are the Lindens willing to make all these ideas possible and if they're willing, how long will it take... If they don't, there will be another platform - the sooner or later - that makes those ideas possible. If they do - it might just take a while for them to implement it... And I'm willing to give them some time...

I do see your point Haruki. Like any large project anywhere let alone in SL, if one wants to convince people to buy, subscribe or even just participate, one needs to build trust. And I totally agree with you when it comes to binding ones solution to something one does not control. Heck we are all sortta doing that with LL. Talk about a 3rd party that can go outta business and put a crimp in our SL business. <crickets chirping>

Our aim is to get things going and "eat our own dog food" for quite a while before offering it out to the general public. The question is do we put the effort into documenting and building good UI that customers require or just rush to completion so we can utilize it ourselves. Anyway thats why I am asking.

Keep up at the top.

I'm still trying to figure out the protocols involved if you aren't implementing the Linden flavor of HTTPRequest or XMLRPC.

The only thing I can figure is a bot app sitting on your remote servers that logs into SL and acts as your intermediary... but by then you are limited by llSay() and any lag present on individual sims...

Intriguing...

But to your original question... if you can pull it off and prove it's robust, that's a potential game changer. Bringing actual application development to SL and delivering seamless data services without the enduser having to download/install/configure anything... incredible.

Hiro,

There's a possibility that you might be asking your question in the wrong place.

Here, you have scripters, who, as you have seen, get stuck in their thinking on "but how you gonna do this?" which of course you don't want to give away, understandably. And even if we did understand how to do this, rather than spend say 10 cents to buy your service, we're more likely to spend 100 hours to see if we can make it ourselves, for the fun of it.

You would need to find a way to speak to the actual potential purchasers of your service, and say, would this interest you.

I see at least two huge drawbacks to e-commerce in SL; no, make that three.

(a) lack of an extra-world communication system with the capacity of what you are talking about;
(b) lack in an in-world ability to have even simple parameters persist (okay, aside from prim name and desc.)
(c) lag. People look at stuff in stores. It doesn't rez in 5 seconds; they're out of there. People can't walk in malls. They're out of there.

I think if we get web on a prim working and evolving well enough, the first 2 of these drawbacks will go away quickly. The lag, I'm not so sure of..