03-01-2012 02:59 PM
This is in Refrerence to an older JIRA which has come back to life due to TPV Policy Change and the use of "DATA_ONLINE" with regards to avatar privacy.
To respect the wishes of Oz Linden this post is started here.
From that Jira https://jira.secondlife.com/browse/SVC-4823
"Oz Linden added a comment - 29/Feb/12 8:52 PM
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)."
03-01-2012 03:00 PM
Within that Jira I offered a solutionm which hopefully LL will consider... I know... don't say it. LOL but I'll post it here for others to see as well. Hopefully this will stimulate discussion as to viable & workable solutions.
Why not simply correct the ONLINE response so that it honours the users choice of "show online status (true/false)" setting. So if a user has elected not to show their online status, OFFLINE is returned, if they elect to show their online status then return the Actual Status. Often the KISS principle being applied is the wisest, simplest & most efficient solution.
- It would not break existing content.
- Does not require the Script Owner / Script Creator validation check.
- It would not be in violation of Privacy, as a user independently selects whether or not they wish their online status available. (almost all forums software, social sites systems, group-ware system use exactly this process and is a globally accepted practise)
- Would reduce the Tylenol Consumption required by LL Staff to deal with the fallout & resulting breakages/issues/complaints.
CAVEAT ! - The only caveat would be vendors / updater's which check a users status prior to delivering an item. These system owners would need to inform the end user that "if" they have their Online Status Display set not show, they would have to manually get updates or whatever arrangement is devised. This is "inconvenient" but not an outright breakage.
EDIT: A mention was made about the overhead of validating online-status-show. Well... one check is less overhead than checking Script-Owner & Script-Creator & Online-Status if passes previous 2 tests. As I have been programming core systems since the ... well too many decades... maybe I just use the "old math" and not the "new-math" when looking at systems.
Seriously, KISS the issue and get back to Keeping It Simple S*.
03-01-2012 03:09 PM
Any proposed solution to respect this BAD policy change overlooks the fact that there is a LOT of content out there to which there will be no updates, and no way for the users to fix when it is broken.
No, I think the entire policy needs to be reconsidered. It is FAR too late to try to put the genie back into the bottle.
03-01-2012 03:18 PM
During the voice meeting, Oz mentioned: "For performance reasons, there's no good way to make that part of the code respect privacy settings." So keeping it simple does not seem to an option...
Which led me to suggest two "opt-in based" possible alternatives.
03-01-2012 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.
03-01-2012 03:44 PM
Thanks, Kelly. While I'm very pleased to learn from Oz's reply in the jira that "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," certainly I would like sometimes to be able to continue to deliver things when I know the recipient is online. I have in mind, particularly, notecards that I'm sending out via a subscriber or list rather than through a group announcement, in the way Zanara Zenovka's PostMaster system does it.
That's got advantages at both ends -- I don't have to worry so much about running into the llGiveInventory throttle, no matter how adjusted, and, as a merchant, I would certainly rather have people receive announcements about new items, updates and promotions soon after they log in, rather than have them delivered offline, because I know they're far more likely to get read that way. It also means I can stop trying to deliver stuff after the event is over, and I can periodically prune my lists, so I'm not clogging up the system trying to send out annoucements to people who never seem to log in any more.
03-01-2012 03:45 PM
The problem has really arose from trying to kill two birds with one stone, which is often appealing but in this case falls a little short of being ideal. Your proposal is a good one that addresses both issue to a degree, although what the original Jira really asks for is a new function to login invisibly, like you get with Yahoo Messenger and I can remember doing with ICQ back in the 90's.
As Kelly points out it would take some major coding overhaul to achieve the desired results I'd suggest the best way forward for now is for LL to keep the scripted funcion but make sure the TPV policy is enforced, TPV's don't need to show true online status as part of the client.
03-01-2012 03:50 PM - edited 03-01-2012 03:51 PM
If it's changed for scripts I am going to have to rework my vendor system I am trying to finish. as it stands currently right now I am having to put it on hold to await to see what the lab is going to do. so awaiting is what I will do.
To edit this a bit, the bridge firestorm or phoenix uses, I get and understand, that's not going to effect how my system works.
03-01-2012 04:08 PM - edited 03-01-2012 05:43 PM
A bounce protocol seems to me the first thing needed by any sensible communication system; whether it is about deliveries or instant messages. I made a(n) (unfortunately angry) JIRA about lack of such protocols a long time ago... after all this is basic 101 in electronic communication.
I still can't believe that communication sent to someone, can go to "dev/null", due to a cap (fair enough) but without proper due bounce errors for failed delivery? Thinking about it makes me bang my head again...
03-01-2012 04:54 PM
I understand your point. It is reasonable.
As a user receiving lots of subscriptions and IM's, I deal with all my 'received' as soon as I get on. Note cards and stuff may get minimized until I get to them. I don't care very much when you send them. I just want to get the ones I subscribed to. If they can fix delivery, I would not think it makes a difference when it is sent, as long as I get it.
When I am in-world and playing in a game or busy, arrival of more stuff gets annoying. At some point I can get annoyed enough I just delete stuff rather than deal with it.
Those playing in combay games can get really annoyed when things arrive during a battle. TPV's with the ability to control all aspects of delivery, toasts, and IM's are popular with the comabt and RP crowd.