WHY Second Life NEEDS an API

Let's forget, for a second, about how badly some of us developers want an API. That kind of thinking doesn't get anyone's attention. No, let's think about the future of Second Life...

Ever hear of the FabLab from MIT? I've been mooning over this conglomeration of tools for the past couple of weeks, dreaming about the stuff I could make if I had a personalized robotic factory at my disposal. Much like the man who dreams of Natalie Portman and thus keeps NP.com at the top of his bookmarks, I've kept the FabLab site close by so I can ogle the future.

While clicking through the site tonight, I came across the wonders that are CNC, and from there I learned about an assembly-like language known as G-code. From there, I stumbled across Collaborative Manufacturing.

If you're a Linden, I strongly urge you to read the article.

The problems this article describes -- cometition between designers and machinists, having to redo work, problems with G-code translations -- are all solvable with Second Life, and API, and a bit of programming. We have tools in-world that can automate the construction of shapes and then output those coordinates into a readable format; how easy would it be to export those coordinates out as G-code? We have tools that allow people to collaborate on a project; how easy would it be for company to run a grid so their engineers and machinists can collaborate on parts? If engineers and machinists can work together and see what they're making together; how fewer errors would there be when it came time to actually produce a new part?

All of this is just for large corporations, too. Imagine a world where an engineer at MIT can collaborate with a machinist in India, through Second Life, and help design a replacement part for his farming equipment, a part that can be manufactured from a nearby FabLab. The possibilities are endless.

The window for this possibility coming from Second Life is narrowing day-by-day. CAD/CAM systems are becoming more the norm. Open source software tools for running systems like the FabLab already exist, and as they're refined, engineers get comfortable with them. If Second Life wants to be a part of the future of personalized, collabortive manufacturing, Linden Lab needs to give developers an API for the client so we can start integrating Second Life into these niches while they are still young.

Second Life needs the API if it wants to compete with open tools. Developers don't need a Second Life API to build a collabortive, 3D environment for collaborative manufacturing. Tools like Lisp, Python, OpenGL, Linux, and more exist and not only can be used, but also have been, to run something like FabLab.

For the record, the first CNC machine built in the 1950's used G-code, and to this day G-code is used. In fifty-fifve years, will Second Life (or LSL) be known as the interface for driving personalized manufacturing? Not without a client API.

Lindens, hire this man.

Serendipity hurts, at times. Message me in-world, please - or a friend of mine if he wishes to be named (I'll refer him to this thread).

I am never going to get any of my own work done...

I suddenly realized what I was missing when I interviewed with LL... I didn't get the Eggy recommendation!

Take care,

--Noel "HB" Wade
(Tread Whiplash)

You would be surprised at how much of what I have said came true.
Fear me, for I hold the key to your future! MWAHAHAH!

I am the one Jefferery Gomez has referred to above. I find this idea interesting in the way that machinists and engineers can collaborate in a 3D environment. In fact, i have used the SL engine to brainstorm several times on machine designs i am working on, to quickly "mock up" designs and concepts to illustrate how a machine might work.

I must say that the prims available to us in SL are not really adequate for any type of real part design. There are very specific tolerances in machined parts often in the range of +/- 0.001" or even less in modern applications. There are also detailed features which would be hard to make by twisting prims or even torturing them to the extreme. Perhaps some simple parts could be made in-world, but these types of things often would not even been drawn. I think someone we know might have a solution to this, but I will leave it to him to say something.

Also, keep in mind that with the advent of CAD/CAM, G-codes are slowly being phased out in preference to what is called CONVERSATIONAL CNC. This way of machining is done right at the machine. The controller ask you questions in normal english and your answers define what the finished part looks like.

I think that the best part of this idea is to allow live interactivity between designers and fabricators. This sort of interactivity is what SL really does well in any area. I would like to talk more about this with anyone interested so please feel free to contact me.

I think it's pretty obvious that SL will get an API; I think you're preaching to the choir.

This is just my thoughts from what I've observed: I think LL wants to fix the bugs and make it actually able to handle all web content before they do so. It takes a lot of money to develop this software, as well, and renting out the servers is a source of income to handle this until SL gets big enough that LL can make money from the other ways.

I've been telling LL that they're missing out on a gigantic corporate market, but they won't listen!
I have designed RL furniture with the SL tools and had it custom made.
My gf wanted some funky shaped shelves for her apartment and asked me to try building her idea here. It worked great.

For sure, Eggy. I think there's a lot of infastructure needed though to prevent that from becoming a free-for-all, though. That's why I call SL the Betaverse, not the Metaverse

good points all. there is a reason that we don't have reverse rpc or an api in general. such things would turn second life into a useful internet tool.

the primary function of second life is to feed a data stream into philip's virtual economy research project. he's already loosing data to enterprising groups, working around the limitations, that are providing offsite services which he can only see as bulk transfers of lindens. ll will do nothing to further damage his dependence on sl as a data collection tool.

the secondary function of second life is to provide data for cory's virtual community research project. a programmable interface will attract developers in droves who'll begin using the world as a testing facility. ll consistently display a collective fear that such an environment will drive away the bulk of recreational players.

finally, second life might, one day, turn a profit. it's not likely either way; but i'm convinced that ll are convinced that it's more likely if they maintain complete control over one interface into one world existing on one grid. if they're going to burden themselves that much, they might as well use it for their own purposes rather than provide a tool for the general population.

this is a 3d social world. we have to look elsewhere for 3d collaborative developer tools.

Object export is too easy to add - as newview essentially gets object export every time you look. That it hasn't been done does likely mean it is not in Linden Lab's best interests to do so in an "open" format.

Pure speculation here as to motivations, but object definition export would potentially reduce the entry barrier for competitors as there'd be tons of content ripe for import. It is not unlike the cellar telephone provider "lock-in" prior to legislated phone number portability; you would be far less likely to switch carriers if it meant that all your callers would need to update their phonebooks.

I'm not saying this is a bad thing ( where did Malachi go?). I'm just noting that this is one place where LL desires and player desires diverge wildly.

nothing to add i just love this quote. guess we know what the first thing you'd make with FabLab is. kiddin!