Difference between revisions of "User:Morgaine Dinova"
| Line 4: | Line 4: | ||
Unix-based by preference and experience, ever since Bell Labs sent me the source tapes. I think that was somewhere around the Late Jurassic period. | Unix-based by preference and experience, ever since Bell Labs sent me the source tapes. I think that was somewhere around the Late Jurassic period. | ||
Language agnostic, too many to care, and several created in passing. The language is not the problem anyway, just a tool with limited scope, so mix'n'match them to meet requirements. In computing, I take the strong engineering line: if you're language-centric and are in denial about interoperation between components from multiple parties written in different languages, then you're not part of the solution but part of the problem. | Language agnostic, too many to care, and several created in passing. The language is not the problem anyway, just a tool with limited scope, so mix'n'match them to meet requirements. In computing, I take the strong, component-oriented engineering line: if you're language-centric and are in denial about interoperation between components from multiple parties written in different languages, then you're not part of the solution but part of the problem. | ||
Currently taking a year or more off for AWG --- seems like a worthwhile goal. | Currently taking a year or more off for AWG --- seems like a worthwhile goal. | ||
Revision as of 21:33, 17 November 2008
Background
Chronologically, ElecEng grad hons, PhD EE/CompSci (concurrency and parallelism), postdoc, and lecturer in EE/CompSci for several years. Then in industry with many clients, freelance contractor in roles of analyst, designer, programmer, systems architect, QA, documenter, and sysadmin, in subjects including kernel, comms, drivers, defence, engineering apps, GUIs, firewall design and management, network monitoring and alerts. and multi-year ISP involvement with service scalability from 64k - 3m users.
Unix-based by preference and experience, ever since Bell Labs sent me the source tapes. I think that was somewhere around the Late Jurassic period.
Language agnostic, too many to care, and several created in passing. The language is not the problem anyway, just a tool with limited scope, so mix'n'match them to meet requirements. In computing, I take the strong, component-oriented engineering line: if you're language-centric and are in denial about interoperation between components from multiple parties written in different languages, then you're not part of the solution but part of the problem.
Currently taking a year or more off for AWG --- seems like a worthwhile goal.
Non-computing interests include many hard sciences and engineering disciplines, especially nanotechnology and its related areas, as well as astronomy and astrophysics, and climatology. Ex-member of IEE and IEEE, ex-radio amateur, ex hang glider, ex guitar player wannabe, and now enthusiastically into MIDI. I'm a long-term transhumanist, which loosely summarises as being interested only in tomorrow, and shedding prior constraints every midnight. Virtual worlds fit in perfectly.
SL background
- Resident since 25th August 2004.
- I spent a year scripting in LSL, but I now regard that as a waste of time. The reason for this is that riding on the shoulders of giants is almost impossible when writing in LSL. To a close approximation, this also means that progress in scripting with LSL is limited to the capabilities of a single person, which effectively means that it has no future.
- My SL interest is currently focussed on working with the Architecture Working Group, an interest which was sparked by Linden Lab's declared Project Motivation (which translates to scalability, scalability, scalability) when starting the AWG project.
SL, and VW Goals beyond SL
System goals
In order of importance:
- Scalability for events (Philip acknowledged the need for it publicly 3 years ago).
- Scalability along the other 3 dimensions.
- Freedom to live our virtual lives in whatever matter our imaginations desire, free of coercion by those whose small minds require that virtual worlds be a mirror of the real world. This is a systemic goal, which impacts on clients, servers, community, and privacy.
- Interop with 3rd party worlds and grids.
- Arbitrary-sized zones, arbitrary-sized plots -- land acreage in virtual worlds has no natural relationship to CPU resources nor bandwidth, but Linden Lab's design has linked resource-based taxation to land acreage, which makes zero sense. As soon as 3rd parties start offering huge estates for L$1 (or indeed whole planets), LL has a financial crisis on its hands. Better start thinking about it now.
Client goals
In no particular order:
- Improve portability across compilers and platforms.
- Remove dependencies on specific versions of required libraries.
- Add an event API for use in scripting language bindings.
- Refactor access to required libraries to allow alternative choices.
- Refactor subsystems to allow alternative choices (see below).
- Decouple the viewing from the presence handling, allow N:1 (multiple views per presence).
- Replace refactored 2D GUI by decoupled alternative [footprint reduction].
- Replace refactored audio system by decoupled alternative [footprint reduction].
- Make the refactored 3D navigation/camera event-driven [for scripting, machinima].
- Attach QA/test modules for test-driven development and system regression testing.
Among the many other benefits, physical refactoring gives us the opportunity to harness multiple cores.
Occasionally I just despair and decide to rewrite the whole thing from scratch. Tomorrow, that is. ;-)
Many of these client-related goals are starting to come together in the Multi-Process Client VAG -- draft. Note that the work is still at a very early design stage.
Personal goals
- Fun. :-)
Enough to keep me busy for a while ...
Feature Suggestions / Ideas Capture
This section is intended for capturing and honing a few ideas before they have a prime-time spot.
Privacy
- See Parcel Basements, by Argent Stonecutter (described in privacy thread post #133).
- This is a very lightweight, server-side-only approach that delivers domain privacy through the simple strategy of blocking the download of objects to clients unless the client's agent is in the same basement as the object itself. It is parcel-based: every parcel has a basement of the same shape conceptually "beneath" it. There are no significant corner cases, because a basement cannot be approached physically, and it simply "doesn't exist" from the PoV of an adjacent parcel basement, nor is it detectable from the land above it.
- The only means of access to a Parcel Basement is by teleport, if granted by the parcel owner. It is a lightweight scheme because object download blocking requires only a single Basement Id check, and because there are no bounding box checks required beyond the existing parcel detection.
- The scheme can be extended to communications privacy as well, by blocking receipt of vicinity chat at the server when it originates from a basement, and replacing it with Basement Chat which is distributed only to those agents that are present in the same basement.
- Privacy in AWG / SL-Next-Generation: privacy is utterly crucial in the context of a worldwide, distributed, third-party virtual world system (a matter of life and death in some cases), but a scheme like Parcel Basements by itself would address only part of the issue. In addition to blocking all basement objects' traffic beyond the bounds of a single managed grid, the communications transport would need to be based on end-to-end encryption between clients whose agents reside in the same basement. The guardians cannot be trusted in principle nor in practice.
- There should be an AWG Privacy VAG to deal with these matters in depth.
Object composition
- One of the greatest constraints in SL which is inappropriate in a more general environment of distributed virtual worlds is that there is no object composition: you can't buy two opaque objects X and Y and create a composite object Z out of them. Object composition is the bedrock of engineering and the key to exponential progress, as without it all products are limited by the capability of individual producers working from raw materials instead of from pre-existing components. In other words, there can be no riding on the shoulders of giants. Instead of building an ever-rising pyramid, all growth is in breadth only, so progress is severely limited.
- Support for object composition needs to be added at an infrastructure level: this means being able to create, refer to and manipulate a composite object as if it were a monolithic one, as well as arranging its constituent parts internally as required. SL does of course have linking of primitive objects, but this is severely limited and cannot build out of existing components.
Interactivity
- See the SL forum thread on extending mouse interactions. This is not an actual feature suggestion, but merely a focus for discussions about adding support for greater interactivity in future virtual worlds of the SL kind.
- Mouselook and loss of camera continuity -- the viewer's 1P/3P camera model is rather primitive, needs a revamp.
- Leave my fricking camera alone! -- the never-ending saga of trying to make LL understand that OFF means OFF.
Materials
References
- The following VAGs are/were of most interest to me:
- I think it's fair to say that VAGs never gained any real momentum.
Drafts and collaborative work
Multi-Process Client
Client-side Scripting
Scalability analyses
- ANALYSIS: Region Subdivision as a scaling method (showing why the idea is fundamentally flawed)