Brainstorming (metadiscussion)

I find this entire wiki construct for this deeply radical change to Second Life to be very troublesome, because it doesn't allow for normal, forums-type discussion about a huge variety of issues that will profoundly alter SL as we know it. So I urge you to cease this driving of ordinary people to a wiki construct that really can't serve their needs, and open up the forums with "general" "politics/governance" and "land/economy" as it used to be available. I see that as the only fair way to accommodate the many concerns, problems, and fears generated by open-sourcing a platform that has absorbed with little recognition hundreds of thousands of people's dollars and hours.

Conversation may flow differently on a wiki, but it does allow for proper conversation if used correctly. --Nik Woodget 04:01, 22 September 2007 (PDT)

It's precisely to avoid "normal, forums-type discussions" that we have wikis. The general idea is to collaborate on creating a jointly agreed entity (a design in this case), as opposed to witnessing a linear string of vocal messages that leave previous useful contributions hidden in the mists of debating history. On a wiki, your contribution remains on the front page if it was good, no matter how many more-vocal people drowned you out on the chat page. --Morgaine Dinova 10:07, 23 September 2007 (PDT)

I would like to know who has authored the articles up to this point. I'd like to know their qualifications for so casually writing things like "Should we close the Lindex or not, given it's a limited license for use on a solely-LL owned grid." Sure, this is the decision of a proprietary company in a way. But the LindEx is also a community-owned resource, that has value precisely because people's labour and content production and land development have value. It's a public utility that you can't so casually program hither and youn.

Quite possible one of the open source devs has written this page. And the question about the lindex is simply something there that we have to consider. Though like you, I would like them to find a way to keep the linden as SL's currency. --Nik Woodget 04:01, 22 September 2007 (PDT)

Zero Linden said that Linden always "engineers to migrate the world along with them." But that very perspective lets us know that we are merely a flock that somebody is supposed to "migrate" like dumb beasts, and not *participants in the social as well as technical engineering.*

we are participants for this open architecture project, you've juse become a minimal participant writting this. Why not add you own things to the Brainstorming you belive needs to be considered in the designing of the open architecture.--Nik Woodget 04:01, 22 September 2007 (PDT)

I predicted that open sourcing would lead to closure of the Lindex for other reasons (dollarization of the economy) but what boggles the mind here is that despite these really huge issues that will have an enormous impact on people, community, value, land, content, it's being treated as a purely technical exercise -- it's being treated as merely an "architecture" program and not an economic one, and one engineers and not economists and land owners get to decide.

like I said, then get yourself and others involved that will look at the economic and social sides and get them to add they're thoughts and concern to the pages dedicated for this in the wiki. The more who discuss, the more ideas we'll have to play, the more chance residents will get an open architecture that they would like. --Nik Woodget 04:01, 22 September 2007 (PDT)

It's anything but a simple programming issue! A decision to close the LindEx has profound implications affecting small business and individual purchases.

Over history, changes in physical technology have always affected adversely those whose fortunes were tied to earlier technological constraints. That is in the nature of technological change. Virtual world technology will change even more rapidly as it is not subject to many physical constraints. Virtual world businesses need to adapt to this dynamic landscape. Agile businesses will probably survive and thrive, but others may not. --Morgaine Dinova 02:03, 24 September 2007 (PDT)

Prokofy Neva

I've split off the above into a "Brainstorming (metadiscussion)" topic, although it's debateable whether it fits here under Brainstorming at all. In any event, brainstorming isn't compulsory, if you don't want to help us, then don't. :-) --Morgaine Dinova 09:07, 23 September 2007 (PDT)

Brainstorming (technical)

All of my main namespace signatures now removed, this line to go shortly. --Morgaine Dinova 19:43, 28 September 2007 (PDT)
Restructured comments under the same headings as main namespace. --Morgaine Dinova 22:22, 27 September 2007 (PDT)

Usage examples and requirements

Viewer

Functional refactoring of viewer

Small section added on refactoring of client into front-end + graphics. I'd appreciate comments and counter-suggestions. --Morgaine Dinova 09:07, 23 September 2007 (PDT)

Tillie, that was an interesting Use Case you added to the viewer refactoring section, ie. "blog editor" type functionality:

It's quite distinct from the earlier Use Cases, in that it isn't attached to a presence but to an object, namely the object being edited. It may be a stretch to call it a viewer because of that, since all other viewers are attached to a presence, even audio-only or script-only "viewers". However, I think you may be on to a good idea there, one related to XML-RPC and other attempts to establish communication between RL agents and SL objects directly.
Perhaps the concept of presence needs to have a number of stages of progressive refinement: first overall presence in a world or grid, then overall presence in a specific zone or region, then in a parcel within the zone, and at the most detailed level, exact location within the zone. Your object editor would then need to establish a presence only at the grid level in order to edit an object there. Likewise, an audio viewer for live concerts would need to establish only a parcel presence, whereas a normal avatar login would require a fully defined presence. --Morgaine Dinova 08:28, 24 September 2007 (PDT)

Note that the event/protocol API exposed by the front-end half of the refactored client should be a language-agnostic API, so that we can create language bindings for it appropriate for different types of platform, including LCCs. In practical terms, this means that it should not be a hierarchical OO API, as this creates substantial problems when embedding languages. --Morgaine Dinova 01:11, 28 September 2007 (PDT)

Commerce

If Second Life is going to live up to its name it should incorporate as many real world activities as possible, and one important area is business. Rather than companies use of Second Life being pretty much restricted to meetings, perhaps this could be expanded to include as many aspects of real world commerce as possible.

Could Second Life eventually incorporate real world stores on the grid where residents could buy items to be delivered to their homes? Or perhaps service industries could be allowed to function on the grid, so for example real world banking transactions etc could take place. It is not a big leap from this to see how online businesses could be developed within Second Life following the models of for example, Amazon and Ebay. - [This has been done by a few already, and is up to developers to take advantage or create the functional connections. Some improvement to external SL communications could help promote this more though.]

Could it be possible to also develop areas such as real world education/training within Second Life with recognized qualifications? I believe a university (or a number of places of learning) within Second Life where recognized qualifications could be gained would attract and help a lot of people. - [I believe the functionality exists for this. Are there specific technical items that are inhibited and need to bee changed to attract a University to start an online learning program in SL? ] --Lusus Saule (attribution got lost in reshuffle, corrected by hand -- Morg)

Note that the brainstorm is for the future, massively scaled and distributed virtual world of which LL's grid will be only one part, and not for the current SL. Some comments seemed to apply to the current SL only.
From a technical perspective, I think the onus is on designers to ensure that the entities used in commerce are supported, ie. currencies, timestamped transaction records (this was exchanged for that), unforgeable documents for contracts, etc etc. Perhaps that deserves mention in the brainstorm. Given a good framework, commerce will come of its own accord, and in the envisaged multinational, distributed architecture, it will probably develop in ways which we never imagined. --Morgaine Dinova 00:33, 24 September 2007 (PDT)

Identity

Added Virtual Identity Verification section. The preceding items seemed to be very "now" and LL-oriented, rather than looking ahead to a worldwide and more distributed architecture. --Morgaine Dinova 00:02, 24 September 2007 (PDT)

Regions

Virtualization of regions

New section Virtualization of regions added, to tie in with the server-side requirements for implementing massive scalability for events.
The same scheme delivers numerous other benefits, highlighted in that section, such as the ability of a large grid to deliver decent performance to its residents when they visit a small external attached grid, through caching. Without such functionality, new worlds cannot easily grow at the periphery, and large grids will tend to be insular.

Implementation thoughts

Viewer (--> Decentralized assets)

Section heading Viewer under "Implementation thoughts" renamed as Decentralized assets, because running a local sim, grid, or asset server is entirely independent of the viewer, even if the viewer manipulates those assets. --Morgaine Dinova 10:32, 23 September 2007 (PDT)

Regions (dynamic)

The [additions] made by Cenji Neutra on 20th Sept are quite strongly related to (or at least overlap with) the changes that I suggest are needed in server-side region handling in order to support the various kinds of SecondlifeTube-type use cases. I would like to start brainstorming some implementation details for these use cases, but ideally I should be cooperating with Cenji on this since he/she must have additional perspective on the issue. Calling Cenji .... :-) --Morgaine Dinova 10:04, 29 September 2007 (PDT)

I've now added a new section Virtualization of regions and started brainstorming this area. Still need to talk to Cenji ... --Morgaine Dinova 03:43, 30 September 2007 (PDT)

Capabilities

Limited Capability Clients

This sounds extremely promising as a concept to me. I've added a Use_Cases#Limited Capability Clients heading, and would love to see a few examples in there. I might add some myself too.
I agree totally on the point about LSL not being appropriate for that kind of scripting, because the object and asset environment of LSL doesn't exist on the client. I'm quite agnostic about languages, but the smaller and more efficient a language the better for LCCs, so Lua stands out by a mile for this. --Morgaine Dinova 21:45, 27 September 2007 (PDT)

I was intending that when scripting LCCs that the script be run on the region and not the client. The client would be partially oblivious to what the region was doing for it. Some aspects of it should require permission or user decisions but most not. The LCC configuration might be easiest to express as a web page (having it as a webpage would reduce the amount of custom software the LCC would have to run to interact with the region). -- Strife Onizuka 23:03, 27 September 2007 (PDT)

Aha, I understand. OK, we have two different scripting requirements then:

Agent-based server-side scripting (this implies that the LSL runs in an attachment or HUD), which performs automatically certain actions which would be either impossible, hard or at least tiresome to perform manually on LCCs.
Client-based scripting which performs local processing on LCCs, eg. triggering the agent-based server-side scripts as described above. As well as issuing those event triggers, client-side scripting would create all local UI objects and use that event API for UI-related communications.

This looks good to me. An LCC might not even have physical buttons (eg. the OpenMoko phone), so the combination of client and server scripting would make up for the powerful capabilities of desktop clients lacking on an LCC. --Morgaine Dinova 00:48, 28 September 2007 (PDT)
I have several LCC-type use cases listed under Functional refactoring of viewer, justifying the need to refactor the client code so that all these very different UIs (some not even graphical) can be accommodated. Now that you've introduced the LCC category, I'll try to rethink that section and refocus it in terms of LCCs where appropriate. --Morgaine Dinova 00:57, 28 September 2007 (PDT)

LCC is just half of the equation. By mixing and matching features things could get really interesting, SLTube is just one example. My next goal is to organize the Capabilities, which has largely already been done for the domain model and more so by the Use Cases. Once that is organized we can look at it's dependencies in the network protocols. But the larger task will be to design the Capability Negotiation system for client & region and client & client negotiations. CN and all the Capabilities need to all fit into a Capabilities Framework, the CF will provide the structures needed for extending SL's capabilities for the future. If CN can be done dynamically then some of the more interesting Use Cases will sort themselves out (you unplug your laptop and it drops the capabilities so you don't use all the battery power, you get on the train and it switches to a passive mode where it syncs the world when it can get a connection otherwise it runs locally). Some of what we discussed at ArchWG meeting went over my head but I think this is the right direction to travel in. CN & CF is what we should be standardizing. -- Strife Onizuka 03:23, 28 September 2007 (PDT)

Good, this sounds like a powerful approach. As long as the CN is done in a sane engineering manner as transitions in a state machine (I really don't want to see add hoc negociations, they are difficult to test with full coverage and often go wrong or leave something out), then state switching for capability changes becomes a very deterministic operation which can be triggered nicely in any number of ways, including from client-side scripts into a tidy API. --Morgaine Dinova 12:00, 28 September 2007 (PDT)

Talk:Brainstorming

Contents