The future of SL: Why not help make it happen!

<foolish walks out, sets back up the table, and pours some drinks on unknown types for people to try>

<takes a seat again>

All right people. Back to work! We were discussing the Future of Second life, and what can be done to help make it happen.

<waits for chatter to die down>

Ok. I get to do this about once a week while I have some downtime on the weekend, so excuse the fact I don't comment on this thread during the week. First life comes first, as it feeds my kids.

Let's begin.


First, we just had an upgrade, and this one was harder than most. Fact is, every upgrade of the client and server software has the potential to break things. This has always been true.

In this case, we got an (i think) upgraded snapshot tool. Mind you, there is some point to having a simpler way to use it as well, but the features and play value of the new camera is beautiful!. What we need in addition is a why to set the snapshot settings in the options menu, and have it where we can also take quicksnaps too. Just set the camera settings you want for it in the menu, and then take easy shots from there with just a hotkey?

Or is that already there?


We also saw our first devistating bug in a while. Seems when certain return object bugs were triggered, it would return ALL the scripted obejcts.

I wonder how many programmer and net techs lost a nights sleep fixing THAT one? Really though, I can see why that got past beta. It was a bit odd to have show up, and I doubt anyone noticed it in the preview.


Both of the above point out to the growing pains of upgraded software. New features sometimes are not well recieved by those who are used to the old system. This is to be expected, and can even be worked around by concepts like I mentioned above. Problem is, you can't always keep the old and the new side-by-side. Eventually, the Client would become an un-navigatable mess with too many options to function.

Now, new features are a good idea, and so is customising systems to a lot of people, so how about this:

Use a plugin system.

I know, I know. It can cause as many problems as solutions, but hear out the thought at least!

Picture if the snapshot system was a plugin that tied into an SL API (programming interface, for you non-software designers). Then, ou could have EITHER snapshot system, depending on what you wanted. Thinks like specialized windows, themes, and other such features would allow also be allowable. Plugins could be things like: Web Browsers, Camera tools, special build macros/tools, and just about anything else you can imagine. We could have huds that tie into plugins that allow total customization of keyboard shortcuts.

In other words, anything we wanted.

Now, could such a system be abused? Aye. It could. The server side would have to be even better armored against external attack. This is a given already, though, since it would be manitory if the server software was opened and the protocals known.

What about the server? Could it not be made to accept plugins as well? What about server side scripting and plugins that allow control over such things as gravity and physics? What about having such things as avatar meshes as server side plugins? They would be transfered to the client side on login. Can you picture a place with a base "furry" avatar that can be morphed into differant kinds of animal types?

So many ideas... Why not give the option of using them all?

<stands up> Any thoughts?

I've been blogging quite a bit recently about Second Life.. Two posts specificly that I think might be of interest to those who follow this thread.

What’s so cool about content creation?
http://www.slinked.net/bs/2006/21

Don’t get it? You don’t have to… Yet
http://www.slinked.net/bs/2006/24

Other interesting things going on recently that relate to how Second Life is improving and expanding(mostly linked from my blog posts above)

Two recent posts about Second Life's protocol improvements.
http://secondlife.blogs.com/ops/

How Many People Will be in Second Life One Year From Today?
http://reuben.typepad.com/reuben_steigers_weblog/2006/07/how_many_people.html

Foolish,

I would love to see a plugin system whereby advanced or custom user interfaces and functions could be defined.

Sorry for the link drop, but there is enough content to fill several posts.

<watches Baba pass out pamphlets>

<rolls up newspaper>

<WHAP>

No CHEATING, you! Discuss in the thread! Bad Baba! Bad bad bad Baba!

<snicker>

Well, not really.

Fine I'll C&P something.. I already wrote a lot ;0 Haha (still cheating)

Don’t get it? You don’t have to… Yet

This started as a comment in response to a blog post by Robert Scoble titled 'On not getting Second Life'

Some people think Second Life is a geek thing. A techie paradise with no real purpose beyond being a cool toy. The truth is, many many people don't get Second Life because it's still very much in development. I can't say that it will become the new Internet. I can say without a doubt it will not replace the flat web.

So, who is not getting Second Life?

The average person doesn't seem to get Second Life. Is it a game? It's got to be a game, just look at it. It's in 3D, and it has little people in it who you move around. Some people don't like games, so they dismiss it. The rest think, "Oh yeah, I like games," and then they look for the objective. When they find none, they decides it's a very bad game, and they dismiss it. The ones that get past that find something that does interest them. It's still kind-of like a game, but

Most geeks don't even get Second Life because they look at it in say the themselves, "Is this my concept of the metaverse? No, it's not there yet." and then they dismiss it. It's not there yet, but it is coming.

For most users or residents, as Linden Lab likes to call them, of Second Life it is a game; a socializing game where they get to buy the latest flash and show off to their friends. The fact is, most of what you will see in Second Life is the Myspace or AOLer crowd gone 3D. It's easy to buy some flashing particles and a trashy outfit and congregate somewhere.

Why should you pay attention to Second Life?

The more important stuff that goes on in Second Life is not quite so flashy. BlogHUD and similar products are the exception to that. Those are the end user applications of the evolving technology. The less flashy development is what is going on with the back-end at Linden Lab and with external projects like libsecondlife.

libsecondlife provides an open source client networking layer that mimics the official Second Life client, which provides third party applications access to in-world resources. Things in development include Instant Messenger applications for various platforms such as Palm and cellphones, account management tools to organize your inventory or transfer funds between accounts, and importing of models from blender using a customized format. Linden Lab has shown great support for the project, though they are unable to share the protocol with developers because Second Life is still closed source.

As for Linden Lab themselves, they are moving towards more consistent protocols, and implementing capabilities through a REST-like interface.

The current system relies on UDP templatized by a message system that changes constantly with each new release as well as XMLRPC. Each change to the message template requires grid downtime for the update. XMLRPC is currently being used for all agent region changes, instant messages, on-line notification, and other miscellaneous services in Second Life. Linden Lab has questioned the scalability of this system, because the query result cannot be easily cached.

Phoenix Linden says on the Linden Lab Ops blog in his post Second Life IPC,The REST capabilities interface will allow system resources to be delegated from the simulator to the client over HTTP as well as offer the inherent cachability of the protocol.

Donovan Linden explains the process this way,It's not just REST. The Mono powered scripting engine has been in development for some time now. This will allow for Linden Scripting Language to compile to CIL which stands for Common Intermediate Language, and even the inclusion of Mono/.Net languages like C#.

What happens in Second Life, stays in Second Life.

Not likely!!! Second Life is busting out of this closed system virtual world mold, and heading for integration. With the development of web-services and the Mozilla browser in Second Life, the users of Second Life will be spreading themselves onto the 2D web from within Second Life. Streaming makes sense. Second Life streams all 3D content and other assets on demand. Second Life has terabytes of content. More content than you ever want to put on your hard drive. At the moment it's all streamlined primitive objects, but bandwidth and processing power are constantly scaling up. Before long, it will make sense to stream raw vertices. With updated graphics and a powerful programming language available, developers will be freed to create almost anything at all.

Beyond just adding features to Second Life, there is Linden Lab's vision of Second Life as just another way to access the Internet. Linden Lab envisions millions of Second Life servers in the future. They could never host them all themselves. It's been said several times over the past several years that Second Life will at some point become open source. If they want to reach a million servers, I think open source will be a requirement. Developing and supporting a technology that is used by millions requires at least one of the following. Open source development, or a huge backer like Microsoft. Linden Lab is not Microsoft, and they don't have a business model that will allow them play on Microsoft's level.

To sum it up, Second Life has access to the 2D web from inside the client. In the near future Second Life will have a REST-like capability interface for webservices, and aplications developed Mono/.Net programming languages in world. Linden Lab intends to open source the server and client at some point.

Second Life is not a closed system, and at some point it's going to have an effect on how you view the Internet. In the future, Second Life may become just another interface to the wide open Internet.

<shakes head> I'm not so sure about that. You see, I see that like having to log into my IM client before I can browse the web.

While I DO think that SL is an excellent platform for 3d communities, I also think that it should be linked, BUT APART, from the web browser. I have no problem with a web browser plugin for SL, and like the idea of plugins that allow:

File transfer by drag-and-drop to other avatars.
Optional Voice chat.
Tie-ins to google earth in order to map sims to RL locations.
Client customization to specific Sims. Can you picture a plugin that has all the animations, avatars, sounds, and so on for a fighting game? Where the keymapping is reworked for proper play of that game?

<side tracking alert>

I think there was a game called 'Heretic 2' that had a mod called blade battle. it was WONDERFUL! Arenas were packed with people waiting their turn on a server until their turn was up and they could go out and fight.

Picture a SL plugin that contained all that was needed to recreate that? With all the animations and such pre-loaded for cleaner play.

<back to subject>

Anyway. I just think that SL is a good platform in it's own right, but to make it, it has to pull it's own weight as opposed to spread out into other's territory. We already have some movers in the browser war. Let them have that battlefield and let's consolidate our hold on 3D communities!

From: Foolish Frost

While I DO think that SL is an excellent platform for 3d communities, I also think that it should be linked, BUT APART, from the web browser.

It will be separate from the web browser... That is the use of Second Life would be just as optional as the use of the web browser from within Second Life.

I don't think the Second Life of tomorrow will be anything like Second Life is today. It doesn't stop with A simple web browser in Second Life and Mono. If Second Life is standardized and open sourced, we may see MILLIONS of severs spring up in just a few years. Possibly only 6-10 years from now. The Second Life of today is more like the test run.. That doesn't mean people are paying to use beta software, rather they're using Metaverse 1.0.

The Second Life of tomorrow is a fully REST compliant aplication. I make mention of Yahoo.com running a Second Life server in a previous post to this thread.



A system like that would function by giving each asset a URI. That URI would track back to yahoo.com and you would retrive the asset to be rendered by your viewer. Your viewer could be A normal 2D browser or a 3D client. Depending on which format your viwer requests you could receive an HTML page or 3D content. You could modify that resource with either, and send an update back to the server.

A simple explaination of REST can be found in a blog post by Ryan Tomayko.

How I explained REST to my wife...

By the way REST stands for "Representational State Transfer" and is a software architechual style that was conceptualized to describe how the web works.

I just had an interesting thought:

When Sl is moved over to mono, and probably C# for scripting (don't worry folks, it's pretty much the same syntax as what you have already), would in not be interesting to have server side and client side scripts?

Client side could do such things as create special windows, control systems, and so on. Server side could do pretty much what it's doing now.

And then have an easy way to communicate between the two!

Of course, you have the same problem with spyware and viruses that everyone does, so it has it's downs as well. Another thing you would have to limit is the client side's access to inventory and the host computer.

Thoughts?

Yes, i've often dreamed of such a thing Foolish.

Maybe not specificly in C# or LSL via mono, because that would require the client be able to interpret/compile the code in some way. Probably by including mono in the release.. Not a good way to keep the Second Life install small.

A better implimentation would be javascript and XUL. XUL is the new interface system in Second Life..

It would be nice if you could squirt an interface widget to someone and the javascript could hook into Second Life and grab data/compute things like how to mirror a build, and then fire off a series of commands to complete the operation.

<Shakes head> I don't see it. A language is just a language for programming. Java, C#, Visual Basic, LSL. It's all interpreted anyway, even if pre-compiled. Same system will work all the way around.

I do like the way you think, though.

how about this: The SL server stores the client side plugins, including scripts, and offers the client a chance to download them for use in the sim. The client downloads them, installs them and activates them as needed, advising the server they are up.

Server ties into the client and the server side plugins then directly connect to the client side plugins, allowing specialized systems to be developed.

What kinds? How about built in voice-chat system? Ones that get fainter as you walk farther away? Internalized video and music streaming on the server, internally, so that outside people so SL could not tie up the stream when not logged in.

Oh! How about the idea I had about digicam face -> avatar control? You smile, your avatar does so too!

All of this could be done with the proper plugin API and design.

Of course, so could nasty kinds of macros and viruses. And that i don't have easy answers to... SL antivirus anyone?

Mono and .Net are runtme interpreters/compilers. They are required to run programs that are programmed using their libraries.

Like with MSN Messenger or whatever they call it these days, you must download the .Net platform.

Javascript is already built into the Mozilla XUL system.

You also can't really write viruses in the Mozilla XUL Javascript interpreter, while running C# client scripts would be like the ActiveX of SL. Download this binary from random Joe and see what happens! Whee...

Isn't that how most people use the internet?

Be good you two. We know how bad it can get if done wrong.

Even if we use C# as a base, we can limit the mono implimentation simply by only making use of a subsection of mono needed for SL.

Just have SL have it's own 'mono' library instead of using the whole thing. Remember, it only has to work inside the SL client, NOT make full windows software.

Excuse us folks. Some of you reading this may not know what MONO is. Or C#. Or any of the above.

What we are generally discussing is the idea of upgrading the programming/scripting language for SL that allows objects to do things. Every item from doors to particle emitters use scripts to function.

MONO is a set of functions that a program can use to do things. A command that moves a prim from one position to another in SL is a function. Groups of functions are called 'libraries', and MONO is effectivly a library of functions that all use a common design idea.

Did all of that make sense?

I still think javascript would be the better option for the interface. It's the language that XULRunner, which is the engine that runs the Second Life interface, uses to perform actions. XULRunner was developed by the Mozilla Foundation to serve as the interface engine for their software releases. The latest version of XULRunner will ship along with Firefox 2.0

XUL stands for XML User Interface Language. It's a way of describing a user interface with XML markup. CSS can also be used to style each element of the interface.

Actions are defined with XBL or Extensible Binding Language. XBL defines for XUL which actions it may perform. Javascript is used to turn the interface into an action aplication that performs some task. Second Life probably does this with C++ because that's the language Second Life is writen in, but for most aplications, javascript is more than enough. Consider that the entire Firefox user interface is written in XUL and javascript.

While javascript is not explicity required and in reality you could use any language to return data to a XUL form and perform actions, javascript is simple and very well known to many people. It also would require less work to implement because it is already the standard used by XULRunner.

It also doesn't involve writing your own implementation of mono, which is always a plus.

Oh, didn't I mention that? Yeah Jim Purbrick is already swamped enough. He doesn't need to write mini-mono to work in the SL client.

Ok. With all the things going on about the last update, and how bugs got into the release in-mass, Let's dicuss solutions to the idea of testing releases for problems before making them mainstream...

Aye. LL is kind of 'damned if they do, damned if they don't' right now. If they don't shutdown and the problem get's widespread abuse, they get accused of not doing anything. Now people are complaining that it's happening during a major event. No one is happy right now, and I sympatize.

The fact that major events happen often, and it's kind of hard to schedule around all of them for patches is beside the point. <shakes head> Aye. A better quality control could help.

How about this idea: What if we have three levels of SL: The Stable, Beta, and Alpha sites?

The idea is this. The stable is the 'real' SL world. Alpha is like the preview sites we have now.

Beta is a smaller, but usable world. It's run like the stable, but seperate. They give heavy discounts to land ownership tier, linden buying, and such. Nothing from Beta can enter Stable without special linden request and payment of a fee, and only if such a device is using tech that will work on Stable.

This would entice a large number of people to use the systems BEFORE they reach stable, allowing tons of time to see side effects of any changes. If a person does not login to beta for a reasonable amount of time during a month, they are removed and someone else allowed to come in. All applicants to beta must be approved. Etc...

Perhaps we could even give discounts/rewards to people who login to the Beta grid and provide bug reports for the main grid. <shrugs> It's open to debate wich would funnel the most manpower into beta testing.

Thoughts?

Hey Foolish. I was going to post something the other day in regards to QA testing here (since it is the future) but didn't. Mainly cause a topic like this basically ends up being like a feature request/suggestion type thing. But since you brought it up I will join in. Hehe. I will simply just add my suggestion into yours.

What I had in mind was creating an Issues Alert Dispatch system. Say someone submitted a bug report. When this bug is fixed, the dispatch system sends an e-mail to the person who originally reported to the bug to verify it has been fixed. This message contains the details of the original report, reproduction steps, as well as a link to the issues page with a button to verify this issue has been resolved. There is a timeframe. If that person does not verify the bug within the timeframe Linden Labs can make the release live as they wish without waiting which in case the issues page will report that issue as "User Unverified" or such.

Something similar would be to create a vote-like system which gives approval/disapprove button that an issue has been fixed. This would be an open user verification system where people can "checklist" through open issues. Or it can be setup to a "Quality Assurance" volunteer group access based system. An example follows...

Issue ID    Description      Status     Rating
001         Some issue A     Resolved   4(TU)2(TD)
002         Some issue B     Resolved   1(TU)0(TD)
003         Some issue C     Resolved   3(TU)11(TD)
004         Some issue D     Open       -
005         Some issue E     Resolved   6(TU)1(TD)

TU = Thumbs Up icon (Approved)
TD = Thumb Down icon (Disapproved)

If there are enough disapprovals LL should hold off on releasing.

I kind of like this. Let's puch it up a notch and begin design on this fictional system!

Ok. First they get a bug report. It's loaded into a database with all the others, and someone walks through each bug report and does one of two things:

- If nothing else seems to match the bug report, then a new ticket is created based on it.

- If an open ticket exists, then attach the report to the ticket.

From there, the tech looks over the amassed information, and tries to reproduce the bug. The bugs with the most reports get worked on first.

From there, it works like offered, he makes a patch, and checks with others after the release if it solved the issue. If a person wants to vote that it is not, they have to upload complete system specs and a detailed explanation of what is still going on.

All individuals have access to the voting, and can see how many others say it's fixed. That way if 99 say it's fixed and one says it's not, the tech can honestly turn it over to support to see if it's something related to the system it's running on.

Once a bug is fixed, the ticket is placed in monitoring state. After the NEXT update (after the fix update) it is sent out again with a question of if it is STILL fixed. If so, then it's closed.

Any thoughts?

When someone bug reports, their systems specs should already be sent with a report. So, appending the report to an existing one is a good idea. Then, a user who logs in to the issues system could check off their dupe bug report as "not fixed" (Adding +1 to the Disapproved status) thus the dev has a system spec and info to run on off this similar bug report.

Yea, some people won't be as fortunate. Perhaps they could e-mail the person with the issue and have them call the support number with a issue ID to refer to so that it could explained further in detail. They could also provide links to Knowledge Base articles and common steps to check.

Sounding good.

Linden Lab has considered a user accesable issue tracking system before.. I don't know where that went though ;0


OH yeah! ;0 And remember ;0

THERE IS NO DATA.
THERE IS ONLY XUL.

<blank look>

We have to kil you now, you know?

<pulls out Mark Three Plama Rifle>

I'd like to say this won't hurt.

...

Yeah. I'd LIKE to say it....

<BZZZZZZZZRP>

By the way, you're invited to my next punwar. When I'm given time to do it.

Anyway, yeah Javascript! It anyone intersted in the user interface? I know it's on the minds of the devs... They're trying to lower the barrier of entry by simplifying the UI for some while retaining the advanced features that other users want.... It's a hard balance to strike..

I weighed in on the issue in my thread

What's so cool about content creation?

/108/fd/122159/1.html

We agree. That's why plugins are the future. It allows any feature wanted, without overloading individuals with things they DON'T want!

As to javascript, we will see. Depends on what the programmers decide!