User:Morgaine Dinova

From Second Life Wiki
Jump to navigation Jump to search

Background

Chronologically, ElecEng grad/honours, PhD in EE/CompSci (concurrency and parallelism), postdoctoral research (parallel language design), and finally university lecturer in EE/CompSci for several years. Then left academia to work in industry with many clients as a freelance contractor. Very diverse roles in computing: analyst, designer, programmer, systems architect, QA, technical author, and sysadmin, in subjects including kernel, comms, drivers, defence, cryptography, engineering support applications (eg. RF power density displays), GUIs, firewall design and management, network monitoring and alerts, automating server farm operation, and multi-year ISP involvement with scalability of services from 64k to 3m users.

Unix-based by preference and experience, ever since Bell Labs sent me the source tapes and I took up residence on a PDP-11/34. I think that was somewhere around the Late Jurassic period.

Language agnostic, used far too many from all the major paradigms to be tied to just one, and created several from scratch in passing. The language is not the problem anyway, just a tool with limited scope, so mix'n'match them to meet requirements. System design should never be driven by choice of language, but the other way around.

Sensible engineers know better than to make a car out of all-rubber or all-steel. In computing, I take a strong, component-oriented engineering line: if you are 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 an open-ended sabbatical (I've earned it) for AWG/MMOX/OGPX/VWRAP/etc --- it seems like a worthwhile goal. Living off savings can't last forever though ... :-(

My main focus in the VW landscape is designing for scalability, open architectures, and high extensibility.

I am strongly pro-FOSS, but abhor the balkanization of open projects by language and license religion.

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 summarizes as being interested only in tomorrow, and shedding prior constraints every midnight. Virtual worlds fit in perfectly.

I'm UK-based, and hate the weather.

SL background

  • SL resident since 25th August 2004. I regard SL as a very nice initial step in the evolution of VWs, but it has poor support for the 'V' in VW (it emulates RL), and suffers from severe scalability problems in almost all areas except sim count.
  • 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. To allow us to ride on the shoulders of giants, we need object composition.
  • 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. LL has expressed no interest in making regions scalable, but AWG fuels third-parties too, so the work is worthwhile.
  • I am a little concerned at the (apparent) disconnect between the AWG's very server-focused view of the OGP design process and the rather obvious fact that it's the viewer that actually drives the protocol, so really it is the viewer that should be setting the requirements. The viewer is actually the "customer" here, in some sense, yet there isn't even a list of use cases that have been analysed to drive the protocol design (beyond the existing, non-interop use cases which are always in mind of course).
  • It is partly in response to the preceding point, and partly in response to LL's disinterest in sim scalability, that I've been looking more closely at the various third-party viewer projects, or forks. Two such are the Meerkat viewer, and the Imprudence viewer. The latter is closely associated with the User Experience Interest Group (UXIG), which was formed when Benjamin Linden reduced his Office Hours to a mere 1h per month, and then stopped appearing entirely. I'm now participating in this group, and in the Imprudence discussions.
  • The AWG/OGP work has now risen to a higher plane as a result of the recent formation of the MMOX group at the IETF. It currently has a mailing list and is planning its first BoF. The goal there is VW interoperability far beyond the SL model. Note that the AWG Use Cases remain applicable. Addendum: the BoF was successful, but traffic on the MMOX list dropped to a trickle as it became clear that there was no way to bridge the huge gap between worldviews.
  • A new IETF mailing list OGPX was created to narrow the scope of the MMOX work to OGP-compatible worlds, and the VWRAP working group was officially formed on 29 Sep 2009. I am active in the discussions, where I tend to uphold the goal of widest possible interop among a plethora of sovereign virtual worlds, and rejection of policy export which is incompatible with tourism. The principle of Destination Determines Policy encapsulates this view in a phrase.

SL, and VW Goals beyond SL

System goals

In order of importance:

  • 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.
  • Scalability along the other 3 dimensions. (The only one that LL implemented quite well was zone tiling scalability in 2D.)
  • 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.
  • Some of these client-related goals have been re-focused into modifications to the Imprudence viewer. In particular, several aspects of Imprudence's forthcoming socket-based plugin system borrow directly from the earlier Multi-Process Client work.

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

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.
  • It is important to point out that Philip and Cory stated publicly in a Google video presentation that in retrospect they had made a mistake in opting for prim linking instead of object composition. I agree. And while SL probably won't get this improvement any time soon, other VWs undoubtedly will, so that the pyramid of engineering components can start growing in height at last.

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.

Camera/navigation improvements

SL's viewer kicked off with a rather interesting and flexible implementation of 3rd Person (3P) camera navigation, quite unconventional because it allows the camera pivot to be decoupled from the avatar. It even attempted to provide continuity between the 3P and 1st Person (1P) views, but unfortunately this failed somewhat in its implementation, and the camera system as a whole hasn't really seen any significant development in recent times.

I have an interest in 3D engine cameras, so I became involved in many forum discussions about it. I expect my interest to be rekindled when 3rd party viewers become more mainstream ... which is any time now, as independent viewers are sprouting up all over the place. Here are some relevant forum threads from way back, which sadly are just as relevant today since nothing has changed:

Design Principles

RISC vs CISC in software

  • Each feature that is subject to a "RISC vs CISC" argument (should it be in core or not?) should be implemented as a dynamically autoloadable accelerator, and if the accelerator is not available then an emulation of it using existing core facilities should be employed automatically.
  • This gives you the best of all worlds -- high portability, small core size, strong decoupling between core and extensions, and speedup where the accelerated operation is available.
  • It also allows you to prototype a feature before you accelerate it natively, and the prototype becomes the emulation for when the accelerator isn't available.
  • During unit testing, failure of the emulation and the accelerator to match behaviors is a test failure, so you even get unit tests for free with this approach.

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.

Agenda items from Linden Office Hours

Zero's OH of Tuesday, 7 April 2009

Discussion re non-local teleport and TP scalability. [PS. It's abundantly clear that once per month is woefully inadequate for AWG to discuss OGP materials with you. As a result, this theoretical channel of communication is not actually open in practice, despite best intentions.]
As Infinity agreed in MMOX, trust agreements don't scale. There hasn't been any discussion about this from OGP designers in MMOX, so it's hard to claim that OGP is rooted in good foundations. [PS. Need more Zero on MMOX.]
In the ZOH of 3rd March, you asked "What else should we add to OGP?". The current lack of any object interop model within OGP and lack of design representation on the MMOX ML is neutralizing our attempts to make progress on this central issue in interop. Therefore I suggest "Let's add OGP: Object Protocol".

Drafts and collaborative work

MMOX IETF Workgroup

Multi-Process Client

PyOGP, a Python OGP Client

Socket-based plugins for the Imprudence viewer

Client-side Scripting

Scalability analyses

Opensim links

IEEE Internet Computing article

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Morgaine_Dinova&oldid=1167740"