I am well aware of how these things work, or in this case, fail
miserably. The interface is simply not intuitive. The implementation is
sloppy, frustrating, and half-assed. 6 out of 10 times when I want to
set up a new grid on a viewer there is some form of hassle involved,
whether it's on localhost or in the cloud.
Having to restart the viewer to reload the configuration when something
goes wrong here is a time loop from hell. I have a moderate to
considerable level of experience with technology, and this is idiotic.
No one that doesn't have a serious reason to will go to this level of
effort in order to browse 3d content.
And yes, sometimes you might want to modify an entry. In the case of
local loopback, with DHCP, I get a different IP address sometimes... So
I have to open a firestorm file, among other things, to modify the
entry. How about a reload button? Because once I put that URL in and try
to apply a new grid, if it doesn't go through cleanly, I am restarting
Firestorm. Sometimes I get the wonderful Not Responding. HOW GREAT THIS
IS. Ever accidentally put a trailing / on there? This aspect, which is
the FRONT DOOR to the entire 'metaverse', is an enormous fail.
Whoever came up with the gridinfo component simply didn't think. How
about an ICON or a THUMBNAIL of the grid you want to connect to, so
perhaps there would be a graphical way of looking at a directory of
grids?
No, we're going to put in a crummy text file with no file extension,
XMLRPC 'helpers' and no real detail about the grid, and "we're" going to
pretend that it's all done, nice and tidy, and move on to ruining
something else by ripping out the entire protocol? While you're at it,
let's restructure all of the INI files AGAIN so that migrating to the
new version is a complete hassle. A 10 year development cycle and this
product hasn't even reached a 1.0 version yet. QUIT IT.
The solution is to make the dialog intuitive, add some form of debug
component to track down issues, perhaps some knobs for timeouts -- and
not to reinvent the wheel of the protocols. Reinvent things once the
original things actually work.
If we are reinventing the wheel of protocols, it's time to set OpenSim
on fire, acknowledge it for the failure it is, and switch over to using
A-Frame, Three.JS, Node, and an entirely different stack. I have already
written one of those. So have others...
There are good reasons for leveraging the existing infrastructure.
Perhaps the methodology of OpenSim is never to finish, but simply to
fail, break everything, and start over again? If abandoning the current
infrastructure is on the road map, then please, let me know, because I
do not want to wait another decade for a basic working solution to what
I'm pretty sure is an attainable goal -- a working 'metaverse' built on
the existing infrastructure -- and I'll happily continue in my
estimation that OpenSim development is insane and will never fulfill
such a basic requirement. It would be a relief.
As for x-grid-info, I haven't seen anything with regard to this
implementation. If it's a proposal and it ultimately fixes the issues I
am bringing up here, bring it on. It could be a quasi-solution. However,
at the present time all I can see is that it is a ridiculous,
failure-prone hassle to add grids to the viewer, and a ridiculous,
failure prone hassle to set them up on the server, and from the
perspective of the end user, it's not going to be worth the frustration.
Even when I'm paid to deal with this sort of thing it's not worth it.
Anyway, I know this won't amount to anything. But seriously, I was here
on day one, a decade has gone by, and this is the FRONT DOOR, and it
does not work properly. And you want to redo the plumbing. No.
On 2018-12-20 10:28, Cinder Roxley wrote:
On December 20, 2018 at 8:32:52 AM, Rob Lindman ([email protected])
wrote:
If people are working on these viewers, especially on matters of URI
handling... it would be nice if there was one (1) ONE with a decent
gridinfo configuration panel. (Preferences -> Opensim -> Made Of Fail)
When attempting to add a test grid... It is exceptionally annoying if
there is some difficulty in adding a new grid. You cannot manually edit
the individual line items for grids in order to adjust the different
pages.
These are constant parameters provided by the grid. They aren’t
settings an
enduser should need to adjust.
It frequently takes a while to fail if there is some difficulty
reaching the /gridinfo file. I wind up with redundant 'lost continent
of
hippo' entries. I was trying to figure out what was going on testing on
127.0.0.1 (which for some reason fails 'despite our best efforts'.)
This is how TCP is designed. You’ll get the same behavior from cURL.
The
timeout is prolonged because there are people running grids on
extremely
latent DSL connections and the timeout period needs to be that long to
connect. I have encountered regions connected to OSGrid that take
nearly
two minutes to establish a connection to.
The /gridinfo URI itself is also ridiculous. Check for /gridinfo.xml or
something... I wanted 'mydomain.com' to be all a user had to put into
this panel in order for it to work, instead of mydomain.com:9000 ...
And
so, hey, I am running apache, might as well just put a file up there
called /gridinfo, that way I can omit the port number while fulfilling
the /gridinfo requirements... While it was 'fun' to mess around with
mod-rewrite... this whole process shows that the OpenSim / TPV
community
didn't put much thought into MAKING IT EASY for people to get on grids.
OpenSimulator hasn’t registered any port numbers in the Service Name
and
Transport Protocol Port Number Registry. Since grid info is served via
http, it is standard to assume port 80. True, most grids host gridinfo
on
8002 (already reserved for Teradata ORDBMS) or 9000 (reserved for
CSListener and php-fpm’s default port) but there’s nothing stating they
are
the standard port.
I ultimately had to open the Firestorm user grids xml file and add one
in manually to access the opensim running on my local system. That's
ridiculous. A typical end user is not going to want to go through that.
I am an opensim / second life enthusiast and this hassle was enough for
me to set the computer on fire. There is no easy way to debug what is
happening here.
This is a DNS resolution issue with Firestorm. Nobody has ever bothered
reporting it to Firestorm, so they don’t even know it exists.
If I had to go through all this trouble every time I wanted to connect
to A WEBSITE then I am sorry to say I would simply become Amish and
start milking goats.
You’ll get a lot of the same issues trying to set apache+php up on
localhost and connecting via loopback if you have no experience or
documentation to help you.
A replacement for LLUDP isn't needed.
Disagree. LLUDP has many limitations which are mistakenly blamed as
viewer
limitations. Not to mention, UDP being the chief reason firewalled
clients
can’t connect. The protocol needs changed or at least DEFINED in order
for
client and server to communicate.
What's needed is for people to
actually think about what they are doing. Try out the software under
different conditions and wonder if a person new to this environment
would REALLY want to contend with the seriously annoying issues that
are
basically in the way of anyone adopting OpenSim.
As far as your example, that’s one of the reasons I created the
x-grid-info:// scheme (and why ArminW created hop:// though it’s
specification morphed) When x-grid-info:// is properly supported, one
need
only to click a hyperlink in a web browser to add a grid to the viewer.
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
---
Rob Lindman
Software Developer
https://roblindman.net/
316-361-6913
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
