Please use reply, not reply all. I get two copies of the mail if you use reply
all. Corporate firewalls generally allow absolutely no UDP traffic. Using the
LL protocol in corporate or educational setups means opening up UDP, which they
are unwilling to do because they see it as synonymous with allowing illegal
file sharing. Go figure. These helper programs in gridinfo are mandated by the
way LL set up the protocol, we wouldn't have them if we didn't have to. I don't
see what you consider wrong with grid info on the server, unless you are
complaining about the name of the link. In that case, you need to try to find
the author of the Hippo viewer, because that is the person who invented that. -
Melanie ---- On Thu, 20 Dec 2018 17:25:53 +0000 Rob Lindman
<r...@roblindman.net> wrote ---- I am somewhat confused by the representation
that the LL protocol doesn't work with firewalls... It would appear that LL has
worked around this issue:
https://community.secondlife.com/knowledgebase/english/using-second-life-with-a-firewall-r599/
What aspects of the protocol do not work within the firewall context? 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 > <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 --- 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
