Indeed it is :) - Melanie
On 10/04/2014 17:25, James Stallings II 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 <mela...@t-data.com> 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 <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 >> >> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 >> > > > > > > _______________________________________________ > 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