[Opensim-dev] Unreal viewer: summoning the coders

Thu Dec 20 17:20:49 UTC 2018

I am aware of who develops what.

Fixes need to be made to /gridinfo on BOTH sides.

/rant

On 2018-12-20 11:58, Melanie wrote:
> 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
> <rob at 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 (rob at 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 at 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 at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

---
Rob Lindman
Software Developer
https://roblindman.net/
316-361-6913