SL API (part two)

They told us why we can't have one, but here's a couple of reasons we need one...

http://profnano.org/hackers/db/sl-browser.jpg
The ability to build a browser in world would make SL much, much more useful. You could access the Wiki without having to leave the window. You could read blogs in world, share web gossip, etc. There's a lot of potential in giving us users an API and allowing users to build client-side-only widgets like a browser.

http://profnano.org/hackers/db/emailer.jpg
This is my favorite, an in-client email interface. People who play Second Life on a Mac have Sendmail running on their system, people using XP Pro and Win2k have an email server, and there are several, easy, ways to put a server on a computer. Putting a client into SL, by way of an API, and plugging it into a desktop server would be awesome.

Anyway, just a couple of ideas that could be used to extend the power and utility of Second Life is they give us an API.

Come on!

Actually, I think the whole feature suggestion forum is a reason to have a plugin client API.

A lot of these features could be implemented by outside developers.

After all, look what the community has done with LSL? I think it isn't much of a leap to assume they'll do the same with an API.

This is a critical feature. We really need this.

What are you talking about? We already have this!

Desktop windows!

J/K! Don't I WISH!!!

Arti

Jesus. That would be incredibly useful!

:: chants :: PLUG IN! PLUG IN! PLUG IN!!!!

Api! Api! Api!

Someone create a group and lets start recruiting.. Seriously, this should be the #1 priority after bugs/scaling/stability..

I think an API could help with some of their scaling issues. Here's how...

Nah.. I think you're on the wrong track there.

Focus on what an API is supposed to - implement features people want (read this forum for these features).

Focusing on what an API can not and should not do, solving scaling issues or implementing features people aren't asking for will simply get the idea ignored.

Nah.. I think you're on the wrong track there.

Except, I think I can be on both tracks. Let me offer this example, that I just made up:

People want First Person Shooters in Second Life. If they had an API they could do ALOT to streamline the interface to make it more FPS-ish. By stream-lining the interface with an API, they could take a load off of the SL network. They wouldn't need an LSL script to keep up with bullets, the client could count mouse clicks; they wouldn't need a bunch of listening scripts to record scores, the client could post that to the web and then the client could pull that down for ranking.

Everything we do now has to be done in-world, which means every improvement that Linden Lab makes has to ultimately be done to the servers. If they gave us an API, not only could developers do what we want to do client-side, we could do a lot of stuff via our own Internet connections that would save SL bandwidth and processing time.

Right now, by my definition, the SL client is a pretty thin one. Maybe not a thin-thin client, since is has a good many menus, but it's no where near as rich as Mozilla is -- and Mozilla's richness doesn't even include the cool web-pagery you can do with PHP, CGI, etc. If SL released an API, allowed us to connect the client to other network services, developers -- both at LL and third-party users -- could get what they want.

it is true that a good api will allow us to add a window that transfers data to and from a user supported host without ever touching the ll servers. add that to the ability to import & export inventory, and ll has offlaoded a LOT of their asset related problems to us and our hosts.