No biting needed :) Debug output is a pretty good start and you did answer my concern when you mentioned the intermittent nature of the issue. I was worried that this would lead to a refactoring frenzy, possibly breaking even the parts that do work, but the fact that it's not consistently reproducible means that you're doing the proper debugging already.
- Melanie On 10/04/2014 17:52, James Stallings II wrote: > So, Melanie, I'll bite: What do you suggest for 'proper debugging' in this > context? > > > On Thu, Apr 10, 2014 at 10:25 AM, James Stallings II < > [email protected]> wrote: > >> The only code I'm affecting the local copy on my server; it isn't as if >> I'm going to break break the central repo back to 2006. Hell, I don't even >> have commit. And FWIW, last I hear adding log statements to code is a valid >> tried and true debugging method. >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 10:23 AM, Melanie <[email protected]> wrote: >> >>> I'm not even being defensive. I just don't like the idea of poking >>> code with a sharp stick instead of debugging it properly. >>> >>> - Melanie >>> >>> On 10/04/2014 17:20, James Stallings II wrote: >>> > "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 <[email protected]> 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 < >>> >> > [email protected]> 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 < >>> >> >> [email protected]> 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 >>> >> > [email protected] >>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >>> >> Opensim-dev mailing list >>> >> [email protected] >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > [email protected] >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
