#SL Viewer Policy Change Meeting

7:00 – The llRequestAgentData() function is going to be broken by the Lab. The Lab is looking at how to change this function to work within the scope of the Lab’s privacy policies. As planned now, the function will ONLY return accurate information on the online status of a person creating or owning the script. For all other requests about other avatars the function will return false.

It is pointed out that for performance reasons the Lab has chosen to make the function work on creator and ownership rather than general avatar permissions. Using the permissions required too much resource time placing too much load on the permissions servers.

10:00 – Online Status Boards – we see these in many shops that show which customer support people are online. These will be affected by the change to the function.

The easy fix is to have the customer service rep paste a copy of the script into a blank script they create. Then give the script to whoever is setting up the boards. Thus the script is created by the rep and will work.

This work around will allow Online Status boards to continue working.

11:00 – Delivery Problems – Another legitimate use of online status is for checking if someone is online before attempting delivery of items. This is used for message announcements and other things. Those uses will break. However, the Lab is vigorously looking at getting the delivery issues of all types fixed. It is believed that Direct Delivery will fix the delivery problems. As you may have read the Received Items phase of Direct Delivery is in testing on the ADITI grid now.

(? Linden) was going to go with some to test how llGiveInventory() works with the new llRequestAgentData(). We start to see problems once messages cap, items being delivered are lost. The standard wisdom is that if one buys something in the Market Place, they be logged into SL when making the web purchase.

(? Linden) says the Lab is very committed to getting the delivery problem fixed. He also says there is SERIOUS effort being expended to get it fixed. It may be interesting to see what happens as other Lindens start to find out how messed up the delivery system is.

13:15 – The question came up about what happens to TPV Dev’s and users with existing viewers that have features violating this online status privacy aspect? It is obvious there are a lot of viewers in use that have the features. Simply said, the dev’s are asked to remove it from future releases. As to the older viewers in use,  (? LINDEN) says he is just not going to worry about it.

This suggests that this is not a major effort to enact a retroactive policy change. Those using older viewers with these features are not going to get in trouble. It is expected over time they will upgrade and lose the prohibited features. I suspect we have so many new toys coming that people will be enticed to upgrade.

14:00 – The ETA for the Function Change?  (? Linden) does not know. But, we can expect the llRequestAgentData() to first change in one of the release channels then roll to the main grid. That would make the earliest possible appearance two weeks away and likely a week or two more.

17:00 – Another user use is an update from vendors that update products when the user logs in. Some discussion but, basically this process will have to change. The Lab has discussed an event that might be added to allow a similar process. But, it is ONLY in discussion stages. (18:40)

19:45 – Client Separators – Geeky stuff, mostly the permissions in your friends list as to whether thay can see you, where you are, and sharing your stuff.

22:15 – A question was asked about Last Online data breaking. As far as (? Linden) knows this will not be a problem. This is the information many use to prune groups membership lists. I expect it to continue as is.

4 thoughts on “#SL Viewer Policy Change Meeting

  1. Pingback: New TPV policy changes - Page 19 - SLUniverse Forums

  2. Hmmmmmm… “trust us we are the new and resident responsive LL”. I’ll believe it when I see it, they have to overcome a lot of negative inertia.
    I did a tally of the New Feature catagory at the jira, OVER HALF are labeled Awaiting Review — (~4000). If LL really intends to be more responsive to feature requests they need to have a better system than the jira. Right now the best avenue we have is to tell the TPV teams, they listen; oh, or we can hire Qarl (if he will ever do it again with all the attitude he has gotten).

    • I understand the negative inertia. Once burned and all… The Lindens are aware of the problem.

      The JIRA is integrated into the work flow of LL. It is also the primary bug reporting and feature requests processes for numberless software projects both commercial and open source. It is pretty high end software for this type of work. It has developed over years. So, what would suggest?

      I know many think the JIRA does not work and the Lindens ignore it. But that is not the case. Go to the JIRA and select any of the Projects from the top menu and check the summary. It gives you items reported and items fixed within the project. As of today there are 67 new issue reports and 42 resolved in the last 30 days.

      That brings us to the ongoing problem of whether to add new features or fix problems with existing features and services. The Lab’s resources are limited. I doubt we will every be happy with adoption rate of requested features.

Leave a Reply

Your email address will not be published. Required fields are marked *