Khamon

Typing the thread title, I asked Jarod how to spell "relevance" and his answer was J.A.R.O.D. I'm having the impression that virtual world developers have learned about all they can from Linden Lab's attempt to build Teh Metaverse and are quickly leaving them in the dust of irrelevance.

Is this true or is my novicane wearing off too quickly?

__________________
But of bliss and glad life there is little to be said, before it ends; as works fair and wonderful, while still they endure for eyes to see, are their own record, and only when they are in peril or broken for ever do they pass into song. - Quenta Silmarillion

Please Visit Our Gardens and Our Website

Quiplash

It may happen, but it ain't gonna happen anytime real soon. The OpenSim initiative, while promising many shiny bells and whistles (HTML on a prim!), is still in alpha stage, only for the true frontier settler at the moment.

My guess? LL has about 1-2 years before its nimbler competitors beat it at its own game.

Briana Dawson

So how are its competitors currently 'nimbler'? Where is the money coming from that will thrust any startup grid ahead of LL.

1-2 years is rather fast to be passing up LL, no?

Maybe 4-5 years? I am not seeing how this can happen in 365 to 730 days.

Clue box, anyone?

Aaron Edelweiss

Heh, I think LL's hit the wall. OpenSim won't do any better because it is based on the same technology, which I don't think is all that great. Opinions may vary. If we see something take the metaverse spotlight away from SL, it won't be a clone, new and improved or not. It'll be a fundamentally different animal.

This is actually why I think two years isn't unreasonable. We're used to thinking about SL, all the development problems, delays, growing pains, and general random feature path. Whatever steals the show, regardless of feature list, will be a lot leaner and meaner, rather than the juggernaut approach of SL.

prinţesă nină

i have seen long-standing, defacto standard companies and their products utterly smashed in short order by upstarts in the past. it is not beyond the realm of possibility for this to happen to ll.
remember, google was started in somebodys garage while yahoo, lycos, altavista, etc were the leaders.

BEARintheMorning

I agree with nină. It's not out of the question for LL to be crushed by any or all of the Open projects. I bear LL no ill will but their track record of development and customer care has burned a lot of very smart people who would like nothing better than to contribute to LL's death.

Aaron, you could be right. However, there's nothing saying that someone or anyone can't take a quantum leap forward with the existing technology once the Open projects are in full swing.

To me, that is what makes this a very tantalizing prospect. Seriously, when the Open projects move past alpha the sky is the limit in my opinion. I've been involved in a lot of open source projects over the years and all it takes is one moment of clarity for someone and a project can explode.

On the flip-side of that, a project can be ruined just as quickly.

Either way, I'm along for the ride - bumps and all.

__________________


You know you're addicted to drag racing when:

During the winter, you roll the windows down just to smell the tire smoke from skidding tires.

Khamon

I'm not asking in the sense of LL having to close shop after all their customers defect to the next great platform, but more along the lines of LL having completed their research, having committed all they can to the industry in terms of trial and error development.

If so, combined with the idea that [melodhrama]crushing competition may appear any day now [/melodhrama], perhaps LL should settle into management their world in the interest of retaining the current user base's loyalty. Or break the world management team off into a separate company under LR so that LL's laboratory atmosphere, testing and research is contained away from the wora'uld and its faithful residents.

Adam Zaius

Heh, I'm sitting back and just reading this thread - but this line isnt true.

I think it's probably worth mentioning that, "compatible != same", it is our long term goal to support a lot more than the Second Life client. Your already seeing little bits and pieces of it via the RealXtend client, and the OpenViewer client has a lot more ambititous goals.

Adam

Aodhan McDunnough

The prize goes to whoever figures out how to handle the asset issue.

Don't discount Linden Labs. We have no idea who is going to figure it out.

But whoever figures it out will probably become a trillionaire and I'm not exaggerating, I'll leave it to you all to figure out why.

Khamon

Figuring Out and Successfully Marketing are two different things.

Adam Zaius

Assets aren't an issue. Or at least they shouldnt be.

A good design uses URI/Ls for addressing things which allows you to spread the load almost infinitely.

Khamon

True, in his second, third and fourth office hours, Zero heavily berated Jarod for espousing this heresy.

Aodhan McDunnough

Try to tell that to the people who lose their inventory.

Things are not so easy to spread when you're talking about the kinds of assets SL uses. We're talking everything from prim hair, textures, soundbytes, scripts and animations, and the avatars themselves of course.

When you talk about thousands (later on millions) of heavily loaded avatars being able to travel to anywhere anytime with no predictability you are talking a messaging nightmare. This is a large volume of messages each one a large amount of data traveling with no way of knowing where it's going to be before the fact.

It's easy to provide a data locator. The fun begins when you have to manage the traffic that results.

As we surf our presence is tiny compared to an SL avatar. What will happen when we have an avatar-driven web where our presence is a huge chunk of data moving through the intartubes?

Adam Zaius

Why is that any of a concern?

Assets are just files. Files are sent around the interwebs in mind boggling volumes every day -- every webpage you visit is transfering a set of files, just like the ones attached to your avatar.

The key is not having a single fallible provider for every single bit of content, and also being able to point to more than one cluster.

Every asset request in SL goes through a single gigantic cluster - if there was URL's used, you could point at multiple clusters, multiple hosts, etc.

Khamon

The flaw, the unnecessary bottleneck, is the sim e.g. when I edit a notecard, instead of my client pulling that card directly from the asset cluster, the sim has to retrieve it and hand me a copy unless of course the sim is too busy doing things that sims should be doing.

When I finally am ready to save the edited version, instead of my client sending it directly to the asset cluster, it has to send it to the sim which, if it has time, will relay it. If the sim is busy doing things that sims should be doing, I'm outta luck.

I use this example because notecards, while being assets, are opened and read by single browsers at a time. They're not represented inworld and never actually need to be loaded by a sim unless they're in a rezzed prim's inventory,handed off by a script running on the server, or manually handed to an avatar, although in the latter cases the inventory record should just be created on demand of the simulator or client sans download to the sim IMHO.

My impression of Second Life since early 2004 is that the database schema are horribly designed without proper key management or even the simplest normalization applied.

Khamon

What am I rambling on about? My curiosity, Adam, is whether or not projects such as opensim and realXtend are still watching LL's development processes for input. Or have they branched into their own research and development techniques after learning all they can reasonably expect to learn from LL's attempts to crack the nut?

Aaron Edelweiss

Heh, when they get rid of the grid model, then I'll hold my breath. Arbitrary meshes, more avatar options, and pretty rendering are great things, but I don't think they're enough.

Actually, even though it's counter intuitive, they may actually hurt in the long run. Those features steepen the learning curve and possibly the system requirements if enough bells and whistles are added to the renderer. Oh I know, prims are inefficient and very limiting, so arbitrary meshes are the logical way to improve. Until you can create a building system that keeps the flexibility, is as easy (or easier) for the laymen as prim building, and requires no external software, you're falling into the engineers trap of designing software for other engineers. Same goes for the avatars.

The asset/inventory system needs to be redone too, though not because of load balancing issues. Actually, take a look at how There's inventory works. Not the backend. That I'm sure you can figure out and improve on whatever model you use. There's inventory is more limited than second life's, but there are a few concepts which might be useful. The idea that nothing leaves your inventory, it's just changes state to in world. The idea that a person manually has to create (or purchase) copies, rather than being able to generate them infinitely from script. That last one a lot of people are going to groan about and it has strange implications for in world building (also over-rated in my book), but it does provide some useful economic and asset limiting benifits.

Even if they end up with something evolved way past second life, they'll always have started from second life, specially if they maintain compatibility. Some ideas will get stuck even if they need changing.

Here's to me being proved wrong.

Khamon

Yes remember how long we dealt with forty character monitors, and to think, we still use qwerty keyboards.

Aodhan McDunnough

It's one notch (or two) above mind boggling because it's in near-real time transmitted to everyone else who is also viewing the same "site" you are, and you receiving info pertaining to other people who are also at the site.

A typical website transmits a set of files to you and to everyone else who is there. But the volume per visitor is fixed and content is solely dependent on the site owner.

In an SL-type site each time someone launches a new animation or sound, or puts on a new attachment, that animation or attachment's presence has to be transmitted to all others who can view that avatar.

SL-type data handling is an order higher than that of an ordinary website.

Current shopping site: You buy a book. Mary buys a book. Neither of you see the other's purchases and don't even know the other is there. As you increase the number of shoppers, the server and connection load rises linearly.

SL-type shopping site: You buy a book. Mary buys a book. BOTH of you see each other buying the books. You see what Mary is wearing and she sees what you wear. As you increase the number of shoppers the server and connection load increase exponentially.

Oh VERY big difference.

You know how long ago IRC channels slow down the bigger the chatroom gets? Then scale that up to avatars and you'll see how bad it gets.

Adam Zaius

Aodhan: The amount of data being sent around like that is fundementally irrelevant - the key is that it's not being served from a central authority. Realistically, you arnt talking any more than about 30 hits per avatar, which is frankly tiny, and nothing beyond the scope of current scaling systems.

Adam Zaius

Heh, alright.

1. Grid is outta there in the long term - infact, we've seen the start of it already courtesy of the RealXtend avatar system where your avatar has a hostname to an avatar server in it, IE, I'm:

Adam+Frisby@au.deepgrid.com

It's never been our intention to keep grid mode for as long as we have, it's there as a crutch because it's simple to do, not because it's a long term objective.

2. Meshes can be manipulated as prims. If you have a 'cube' mesh, you can treat it almost the same as a SL cube in terms of stretch/move/rotate/etc, but prims are still there -- we've got the best of both worlds.

3. Asset system needs to be annihilated with something like WebDAV where you can pass around a URL to an asset, and that's it. Inventory needs reworking.

4. Yep - we do have SL compatibility still on the drawcards for a while, but hopefully we get the chance to contribute back new features to SL (the SL viewer license is a big roadblock to that right now)

Aaron Edelweiss

Sweet, in that case add the ability to create end edit arbitrary meshes within the client (though not necessarily in world), and if you can create a toolset to do so that's simple and intuitive enough, then I'll be suitably chastened.

Oh, and as a feature request possibly related to the demise of the grid model, traversable void space please.

Also, I added more to the bit about assets. Sorry, I have a bad habit about going back and editing my posts a thousand times as I think of more to add, instead of creating a new post.

Aodhan McDunnough

All that means is the exponential scaler has been reduced. The volume will still grow exponentially with avatar number increase. Spread out in a P2P fashion it's lightened a bit, but there still comes a point that the whole thing will bog down.

So as long as the number of avatars visible to each other remains strictly capped, then the problem is manageable.

But this of course translates to "sites" with very limited simultaneous visitors. Not unlike a popular restaurant with very limited seating.

Adam Zaius

Only if you dont factor in things like sharding.

Client framerates will be a killer preventing you from having 10,000 avatars in one space. I doubt it will go above 200-400 in most circumstances which is still a very finite number, and quite manageable.

Anyway this is sidetracking from my original point - the asset system isnt complex, and is better served by using URI's and a system like WebDAV than the current rubbish single cluster -- and the problem of missing/losing assets is caused by this single cluster being difficult to scale properly, something URL's doesnt have to worry about.

Khamon

It's interesting to go back and read some of the discussion about URL-based assets. The Lindens always seem to fall back on the premise that infrastructure updates are not necessary because they don't see anyone doing anything inworld that would use those services without understanding that people can't do those things because LL didn't provide the proper infrastructure for it. Go Figure.

Anyway, here is us talking about replacing texture keys with URLs and here is Jarod rambling to the moon about using an AJAX API to drop inventory into people's accounts ha ha ha oh and the grandfather of all quotes "http is the new filehandle. rss is the new |" - Jarod Godel