"Maybe a good starting point is to see what you would like that doesnt' work before you go and fix things that..."
Actually, that *is* where I began. My user reports various failures, which are repeatable on the running regions. No amount of reconfiguration predictably affects the experience on the regions. We do have a couple of regions that seem to work perfectly, including that which I'm working with; it started working after I completely replaced the OpenSim.ini with one that was identical excepting the http_listener specifcation. Unfortunately, repeating this process with the same OpenSim.ini on a different region that doesn't work did not produce a region that does. To say that it works intermittently is a bit of an understatement; though it does seem that once it begins working it continues to do so. Try not to be so defensive Mel; I'm not attacking you or your work, I'm just attempting to figure out what's happening on these regions. I have eliminated everything I can find but the code, which I am told by others is not to be trusted as fully functional; and I am not afraid to get in and get my hands dirty. Cheers James On Thu, Apr 10, 2014 at 10:10 AM, Melanie <mela...@t-data.com> wrote: > The code for parcel access works, as far as I'm aware. It was > originally fixed in Avination and that should have been donated to > OpenSim a long time ago. Maybe a good starting point is to see what > you would like that doesnt' work before you go and fix things that > aren't broken. > > Melanie > > > On 10/04/2014 17:05, James Stallings II wrote: > > Subsequent work (instrumentation to Scene) shows that the permissions > > checking code is also being called twice there. > > > > Cheers > > James > > > > > > > > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < > > james.stalli...@gmail.com> wrote: > > > >> After some further exploration, I have seen where the method calls > taking > >> precedence from out of Scene are handling ViaLogin; but they are also > doing > >> some of the same lifting performed in the Land Management module. This > >> seems to be duplication of effort, if not duplication of code; and is > >> certainly less elegant than I would hope to find in our codebase (in an > >> ideal world ;) > >> > >> This is likely the result of the ad-hoc nature of the development life > of > >> the project over the years; I can see the scene code being a good deal > >> older than the Land Management module. > >> > >> I'll be working with this throughout the day, hoping to improve the code > >> as I'm able; your thoughts, advice and commentary are solicited and > >> appreciated. > >> > >> Cheers > >> James > >> > >> > >> > >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < > >> james.stalli...@gmail.com> wrote: > >> > >>> Greetings Devs :) > >>> > >>> I have a use case that requires the unlikely and less than popular > parcel > >>> permissions access control featureset. > >>> > >>> Historically speaking, this has not been an area of development that > has > >>> seen much love, and understandably so; none of us are particularly > >>> interested in fully duplicating the operational envelope of the Second > Life > >>> experience. That coupled with the ability to deploy regions at whim, > it is > >>> no wonder no one wants to involve themselves particularly deeply with > >>> making this work properly. > >>> > >>> That being said, I have a need at present, and there is also the simple > >>> fact that we have a dearth of UI components in the viewer we may well > never > >>> get shut of, and a lot of of unfinished and/or unpolished code in the > repo > >>> that touches on this functionality. > >>> > >>> The short story is, it may be above the waterline, but there is a hole > in > >>> the boat, and one of my users is driving it headlong into the surf. > >>> > >>> So much for metaphors. > >>> > >>> I have heard a variety of conflicting reports about the state of this > >>> part of the codebase; some say it works well; others say it should not > be > >>> counted on to work at all. The commit logs tell the tale that some have > >>> taken an interest and are working diligently to eliminate certain bugs; > >>> unfortunately, the work in progress has not yet brought the > functionality > >>> into a state where it is yet useful, at least according to my testing. > >>> > >>> I'm not unwilling to undertake the work needed to bring this situation > >>> into a more satisfactory light; indeed, I've already begun, and I need > only > >>> a little guidance today. > >>> > >>> I have thoroughly instrumented the method "public void > >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int > >>> localLandID, UUID regionID)" > >>> in the land management module, and was immediately confronted with a > >>> couple of surprises: > >>> First, when the code is called at all, it is called twice; and as far > as > >>> I can tell, it is called only after a successful login has been > completed. > >>> Neither does it seem to be called when an avatar teleports into the > region. > >>> > >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, out > >>> string reason, ref float posX, ref float posY)" is called from > >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and > >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates > (rather > >>> less than consistently) whether the avatar is allowed into the parcel > on > >>> the region. > >>> > >>> Being aware that there are several ways for an avatar to enter a > parcel, > >>> which I will leave off enumerating at present, I would suggest that > perhaps > >>> I have some misapprehensions as to the proper stages of authentication > at > >>> login-time. > >>> > >>> So my question is this: should both of these functions come into play > as > >>> an avatar enters a region (and consequently, a parcel)? or should > there be > >>> a single methoid conducting these presence permission checks? > >>> > >>> Please advise at your convenience :) > >>> > >>> Many thanks and cheers > >>> James/Hiro > >>> > >>> > >>> -- > >>> =================================== > >>> http://osgrid.org/ > >>> http://simhost.com > >>> http://twitter.com/jstallings2 > >>> > >>> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev