1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
Web browsers are a fact of life, both in and outside of the virtual
world. Inside the world, SL people love to play youtube videos on their
virtual big screen TVs to show their friends. Business people want to
gather around a web browser at meetings. MOAP is a thing. Other social
media is a thing, most of it web based, and people might want to share a
tweet by showing their virtual laptop to their virtual friends in the
same virtual room. Outside of the world, SL and OS based grids have
always used a web page for their front screen in viewers. Some of the
tools are web based. People even want to run their virtual worlds
inside a browser.
So we need a web browser that can run on meshes and prims, as well as in
windows (separate or internal windows). As well as being able to handle
our protocols. The problems are (legion) ...
Web rant
--------
Damn the web sucks.
This bit will be filled in next time I feel like ranting about the web,
but damn it sucks really badly.
Bloated, slow, horrid, inconsistent, over complicated, ... , it sucks.
Less of a web rant
------------------
OK, so in typical SL based viewers, the web browser component makes up
about one third of the entire viewer package. At first, when Java in
the web browser was more of a thing, matrix-RAD tried to work with the
web browser. Now we are (hopefully) designing the next big thing to
replace the web, so we get to do things differently. So now we can
(hopefully) treat the web as a second class citizen that we begrudgingly
support as a legacy thing. Note that we are proudly using HTTP as the
bulk transport agent, it's the web content standards that suck.
If matrix-RAD was any indication, I can replace everything that a fully
bloated web browser can do, in something the size of a typical web page
of today, and STILL be better! lol
Actual plans
------------
First of all, try to use and encourage the matrix-RAD style stuff as the
UI of choice for in world stuff. It should work across the network
transparently as matrix-RAD does. This was my HTML replacement that
worked within web pages. Now we can dispense with the web pages all
together. The original matrix-RAD included a plan for a translation
layer, any web browser that didn't like Java could get a "legacy" simple
web page version. We could do something similar, or go up a step and
translate Lua into ECMAScript, or wasm. There's a project that has done
so already -
https://kripken.github.io/lua.vm.js/lua.vm.js.html
LB started writing a web based world viewer, and is interested in adding
it to SledjHamr. She would only have to write the 3D viewer part (which
she is doing), and the wire protocol Nails. Nails being designed for
being wrapped in popular protocols, she could pick one. The client side
UI layer would also need to be written, but that's part of the
matrix-RAD type stuff, so my job.
So I think we could use multi flavours of web browser.
Include something small like Dillo or NetSurf as the built in web
browser. It should be able to spread itself across in world objects,
meshes and prims, as well as run in internal or external windows.
As the next step up, an optional module could replace Dillo / NetSurf
with a bigger browser component, based on one of the main ones, CEF or
uzbl for instance. Hopefully it can be spread across an in world object
somehow.
Finally, the user can always decide to show any given URL, or already
displayed web page, on an external web browser of their choice, with
their default browser being the top choice. Which naturally should be
able to use the in world matrix-RAD type stuff via the translation layer
(CEF can, uzbl should be able to as well, NetSurf maybe, if I remember
they where adding an ECMAScript engine, or had already? Dillo I don't
think does ECMAScript at all).
|
