I believe you may well not be on the same page as the rest of us. We have no
intention to change the Linden Labs based viewers. The viewer developers are a
completely distinct team. The grid info dialog used to be different in the days
of Hippo, it has since been slimmed down by the Firestorm team. We are the
opensim developers, though, and we don't work on the LL based viewers. We are
looking to implement a completely new viewer that of course will have a new
protocol. the LL protocol has always been a stumbling block for the hypergrid
as well as a number of other things. We would not want to base a new viewer on
a broken protocol, that, on top of all else, doesn't traverse firewalls. If you
have a beef with the way Firestorm is doing things, you will need to complain
to them. We don't have any control over it. - Melanie ---- On Thu, 20 Dec 2018
16:36:21 +0000 Rob Lindman <r...@roblindman.net> wrote ---- 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
(r...@roblindman.net) > 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 >
Opensim-dev@opensimulator.org >
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev --- Rob Lindman
Software Developer https://roblindman.net/ 316-361-6913
_______________________________________________ Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
