User:Morgaine Dinova - Revision history

Morgaine Dinova: /* IEEE Internet Computing article */

2012-05-27T23:41:50Z

IEEE Internet Computing article

← Older revision		Revision as of 16:41, 27 May 2012
Line 184:		Line 184:
	=== IEEE Internet Computing article ===		=== IEEE Internet Computing article ===

	* [[IEEE Internet Computing: VWRAP for Virtual Worlds interop]]		* [http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-Interoperability-mic2010010073.pdf IEEE Internet Computing: VWRAP for Virtual Worlds interop]

Morgaine Dinova: /* Multi-Process Client */

2010-05-05T01:58:01Z

Multi-Process Client

← Older revision		Revision as of 18:58, 4 May 2010
Line 162:		Line 162:
	=== Multi-Process Client ===		=== Multi-Process Client ===
	* [[Multi-Process Client VAG -- draft]]		* [[Multi-Process Client VAG -- draft]]
			* [[Proxies as Components of VW Clients]]

	=== PyOGP, a Python OGP Client ===		=== PyOGP, a Python OGP Client ===

Morgaine Dinova: /* SL background */

2010-03-14T15:58:46Z

SL background

← Older revision		Revision as of 08:58, 14 March 2010
Line 28:		Line 28:
	* 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).		* 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 [http://meerkatviewer.org/ Meerkat] viewer, and the [http://imprudenceviewer.org/ Imprudence] viewer. The latter is closely associated with the [[User Experience Interest Group\|User Experience Interest Group (UXIG)]], which was formed when Benjamin Linden reduced his Office Hours to a mere 1h per month. I'm now participating in this group, and in the Imprudence discussions.		* 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 [http://meerkatviewer.org/ Meerkat] viewer, and the [http://imprudenceviewer.org/ Imprudence] viewer. The latter is closely associated with the [[User Experience Interest Group\|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 [https://wiki.secondlife.com/wiki/MMOX MMOX] group at the IETF. It currently has a [https://www.ietf.org/mailman/listinfo/mmox mailing list] and is planning its first BoF. The goal there is VW interoperability far beyond the SL model. Note that the [[Use_Cases\|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.		* The AWG/OGP work has now risen to a higher plane as a result of the recent formation of the [https://wiki.secondlife.com/wiki/MMOX MMOX] group at the IETF. It currently has a [https://www.ietf.org/mailman/listinfo/mmox mailing list] and is planning its first BoF. The goal there is VW interoperability far beyond the SL model. Note that the [[Use_Cases\|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.

Morgaine Dinova: /* RISC vs CISC in software */

2010-03-14T15:49:51Z

RISC vs CISC in software

← Older revision		Revision as of 08:49, 14 March 2010
Line 120:		Line 120:
	* 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.		* 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.		* 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.
	* ~~In addition, 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.		* 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 =		= Materials =

Morgaine Dinova: /* Materials */

2010-03-14T15:49:03Z

Materials

← Older revision		Revision as of 08:49, 14 March 2010
Line 114:		Line 114:

	* [http://forums.secondlife.com/showthread.php?t=41729&highlight=disable+automatic+camera+movement Leave my fricking camera alone!] -- the never-ending saga of trying to make LL understand that '''OFF''' means '''OFF'''.		* [http://forums.secondlife.com/showthread.php?t=41729&highlight=disable+automatic+camera+movement Leave my fricking camera alone!] -- the never-ending saga of trying to make LL understand that '''OFF''' means '''OFF'''.

			= 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.
			* In addition, 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 =		= Materials =

Morgaine Dinova: /* Background */

2009-11-06T06:36:06Z

Background

← Older revision		Revision as of 23:36, 5 November 2009
Line 4:		Line 4:
	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.		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.		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 ... :-(		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 ... :-(

Morgaine Dinova: /* Background */

2009-11-06T06:35:33Z

Background

← Older revision		Revision as of 23:35, 5 November 2009
Line 4:		Line 4:
	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.		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.''' 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.		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 ... :-(		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 ... :-(

Morgaine Dinova: /* Background */

2009-11-06T06:33:12Z

Background

← Older revision		Revision as of 23:33, 5 November 2009
Line 4:		Line 4:
	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.		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. 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.		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.''' 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 ... :-(		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.		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.		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.

Morgaine Dinova: /* Background */

2009-11-06T06:27:12Z

Background

← Older revision		Revision as of 23:27, 5 November 2009
Line 4:		Line 4:
	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.		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, 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 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.		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. 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/etc --- it seems like a worthwhile goal.		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.		My main focus in the VW landscape is designing for scalability, open architectures, and high extensibility.

Morgaine Dinova: /* SL background */

2009-11-06T06:05:28Z

SL background

← Older revision		Revision as of 23:05, 5 November 2009
Line 24:		Line 24:
	* 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).		* 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 [http://meerkatviewer.org/ Meerkat] viewer, and the [http://imprudenceviewer.org/ Imprudence] viewer. The latter is closely associated with the [[User Experience Interest Group\|User Experience Interest Group (UXIG)]], which was formed when Benjamin Linden reduced his Office Hours to a mere 1h per month. I'm now participating in this group, and in the Imprudence ~~forum~~.		* 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 [http://meerkatviewer.org/ Meerkat] viewer, and the [http://imprudenceviewer.org/ Imprudence] viewer. The latter is closely associated with the [[User Experience Interest Group\|User Experience Interest Group (UXIG)]], which was formed when Benjamin Linden reduced his Office Hours to a mere 1h per month. 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 [https://wiki.secondlife.com/wiki/MMOX MMOX] group at the IETF. It currently has a [https://www.ietf.org/mailman/listinfo/mmox mailing list] and is planning its first BoF. The goal there is VW interoperability far beyond the SL model. Note that the [[Use_Cases\|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.		* The AWG/OGP work has now risen to a higher plane as a result of the recent formation of the [https://wiki.secondlife.com/wiki/MMOX MMOX] group at the IETF. It currently has a [https://www.ietf.org/mailman/listinfo/mmox mailing list] and is planning its first BoF. The goal there is VW interoperability far beyond the SL model. Note that the [[Use_Cases\|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 [https://www.ietf.org/mailman/listinfo/ogpx OGPX] was created to narrow the scope of the work to OGP-compatible worlds, and the [http://www.ietf.org/mail-archive/web/ogpx/current/msg00415.html 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.		* A new IETF mailing list [https://www.ietf.org/mailman/listinfo/ogpx OGPX] was created to narrow the scope of the MMOX work to OGP-compatible worlds, and the [http://www.ietf.org/mail-archive/web/ogpx/current/msg00415.html 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 =		= SL, and VW Goals beyond SL =