As many know the various online status boards, pagers, and subscription devices were expected to break and stop working when llRequestAgentData() was changed. That change was expected to roll to the main grid in a couple of weeks. That feature change is now on hold.
This is the JIRA item where the details and issues of the change were being collected. The JIRA item now has quite a few legitimate use cases. There are still lots of people that have yet to figure out the JIRA is not a forum for discussion.
The large number of legitimate use cases apparently surprised the Lindens. They are now considering how to provide for the legit use cases and still disable the griefer aspects. See: SVC-4823. Oz Linden has made a couple of posts in the JIRA and several Lindens have been following it.
Oz’s most recent post is here:
Thank you for the excellent descriptions of problems with this proposed change.
We have decided to defer any change to llRequestAgentData until the important issues raised here have been addressed, especially those regarding delivery to off line users. It is very likely that any scripted object using this method to query agent presence will need to be updated when we do make changes, but we will make every effort to provide ample notice and to ensure that reasonable methods to solve the use cases described here are available.
Interested users are encouraged to Watch this issue and the LSL Scripting Forum for updates.[and from another post:]
Note that usage of llRequestAgentData or any other mechanism to circumvent privacy protections as a viewer component is still prohibited by the Policy on Third Party Viewers.
Ideally, we would like to adjust things so that it’s possible for scripted object deliveries to be reliable even when the recipient is off line, removing the need for this check altogether.
However, it’s too soon for us to be talking about possible approaches; watch the Forum (and let’s not use this issue as one).
In the Beta Server group meeting Simon Linden says they think that some type of change that will meet the needs of legitimate users and provide users time to make needed changes.
Whitestar Magic, who I first met on OSGrid, opened a thread in the forum for discussion of the topic. See:
Kelly Linden has addressed a common solution that people are proposing. (Link)
2012-03-01 03:19 PM
I believe Oz was hoping to stem the tide of armchair development on how we should fix it. It is far more valuable to us to hear how it is used. Hence why in what you bolded: “it’s too soon for us to be talking about possible approaches”.
That said, using the existing flag for ‘can everyone see my presence’ is a very popular suggestion that I would like to briefly touch upon.
I want to assure everyone that I have *absolutely* investigated that possibility. I think it has some significant downsides in the aspects of code complexity, expectations and usability.
- Code complexity: It is unfortunate this this flag is really not in the right place to easily use and would require significant code refactoring – while probably a good thing to do it would require significant effort for development and testing beyond what you would naively expect.
- Expectations: It has never been expected that this flag would control online visibility to scripts and while it might be reasonable to extend it’s features in this way changing the meaning of any long-standing feature should be undertaken with great care.
- Usability: it would be quite reasonable to only want scripts to have access, or only some scripts, or no scripts while still allowing profiles to show online status- none of which would be possible if re-using this flag. Even then it doesn’t solve the very significant problem of item delivery and several other mentioned needs.
In short: we are aware of that flag as an option and it is under consideration but is not as clearly an ideal solution as it may first appear to be.
Join the discussion.