[slscripters] Breaking of LSL ability to see online status with "fix" for SVC-4823
Latif Khalifa
be able to tell online status of their owner and their creator. I
would like if Kelly could clarify if it is true that the scripts will
not be able to tell online status even for those that allow it?
This will break a ton of content. Has any Linden been around the grid
and see how many advertising panels are around the clubs?
The only people affected would be open source script developers. Not
that I want my online status hidden, but everybody out there can get
any of my scripts and copy paste online code and check the status.
While the people that don't want status hidden would be shown as
offline.
Can it really be true that this is implemented in such a way?
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Bryon Ruxton
"[for] all other cases it will return the status per the user's privacy
setting"
So as for your "even for those that allow it?" I think you are misreading.
And I don't know how that would affect advertising panels in any way...
Such privacy policy scope is no different that any messenger like Msn,
Skype or Facebook chat. You just have to live with it.
That said, I have mentioned excluding groups, and group 'scripts' to be
excluded from such privacy policy, which I think is a fair middle ground
and necessity for allowing legit use.
https://jira.secondlife.com/browse/SVC-4823?focusedCommentId=312333#comment
-312333
To my knowledge groups don't abide to online status privacy settings and
rightfully shouldn't.
Latif Khalifa
status read user preference and works for all that have allowed their
online status to be public, or is it *only* 2 people's online status
that will work: script creator and object owner.
Ima Mechanique
according to the recording I heard of the TPV meeting this was discussed
at, Kadah is mistaken. The server will return FALSE for ALL calls not
from the creator or owner of the script, regardless of privacy settings.
http://lecs.opensource.secondlife.com/tpvd/meeting/2012-02-24.mp3
05:00 - 08:00+
Paraphrasing Oz at around 09:20:
For performance reasons, there's no good way to make that part of the
code respect privacy settings.
Ima Mechanique
Check List
1) Check the documentation.
2) Drink coffee.
3) Check the documentation again, to see what I missed first time.
4) If I still can't solve it, ask if anyone else has the answer.
ima.mechanique(at)blueyonder.co.uk
Bryon Ruxton
and an obvious incontestable policy decision that had to be made to
respect basic privacy.
Apparently groups are not yet considered into this.
I guess groups are the next to review as far as privacy policy is
concerned.
I really would emphasize the need for a set-to-group script to check
against its group member's status. At the minimum, 'if the person has a
group tag on' it should be able to get online status. Not having this
inhibits some very legit use like employees within groups or multi-sim
games or activity.
Even if that has performance implications for this, the large amount of
online status calls which are going to be saved as a result here, should
leave room for group scripts calls for online status of active group
members.
Ima Mechanique
> and an obvious incontestable policy decision that had to be made to
> respect basic privacy.
>
> Apparently groups are not yet considered into this.
> I guess groups are the next to review as far as privacy policy is
> concerned.
>
>
> I really would emphasize the need for a set-to-group script to check
> against its group member's status. At the minimum, 'if the person has a
> group tag on' it should be able to get online status. Not having this
> inhibits some very legit use like employees within groups or multi-sim
> games or activity.
I don't know what you mean by "set-to-group script" but I suspect it's
unnecessary. I can think of ways to redo online boards and the uses you
mention, to use current features of LSL. What's more, it would be opt-in
and so put the control back were it should be, in the hands of the
person whose privacy it is.
Oh and it would probably be a lot easier and quicker to implement than
waiting for LL to find a way to make the backend do what you want,
provided they're inclined to do so at all.
Ima Mechanique
I suspect the main reason for this change isn't particularly the
"privacy" issue. As mentioned in the recording, there are numerous ways
to find someone's online presence.
There are a lot of these scripts out there polling the sims regularly.
Some are probably polling *far* too often and being a problem. In one
broad stroke LL can make a whole bunch of legacy scripts useless and
force us to update to more modern, less abusive ways of doing the same
job ;-)
Bryon Ruxton
(grid-wide) of that group's active members, regardless of privacy settings.
> Some are probably polling *far* too often and being a problem. In one
broad stroke LL can make a whole bunch of legacy scripts useless and
force us to update to more modern, less abusive ways of doing the same
job ;-)
> Oh and it would probably be a lot easier and quicker to implement than
waiting for LL to find a way to make the backend do what you want,
provided they're inclined to do so at all.
Nods I agree, nevertheless it doesn't hurt to suggest what "could ideally
be done" by 2032 if they are given sufficient resources by then to tackle
the JIRA monster. :P
Tillie Ariantho
> I mean for a "group owned" script to be able to get online status
> (grid-wide) of that group's active members, regardless of privacy settings.
What kind of usecase is that for? I mean, what for would I need the online status of all members of a group?
Tillie
Zamiel
> On 25.02.2012 11:21, Bryon Ruxton wrote:
>
>> I mean for a "group owned" script to be able to get online status
>> (grid-wide) of that group's active members, regardless of privacy settings.
>
> What kind of usecase is that for? I mean, what for would I need the online status of all members of a group?
>
> Tillie
A device that pages the Online-only Staff members of a group comes to
mind, something that Land Rental groups use.
What I notice about this change is that it combines with the recent cap
on scripted IM/Inventory sends to cripple Subscribe systems.
Although I suspect that might be the intent, they do seem like they're
rough on a number of LL's systems, from what I know of how they work.
Bryon Ruxton
communication to all or any members of the group across the grid,
dependent with their online status.
Sample cases:
- A help desk that track their online members across the grid.
- A multi-sim game that track active playing members.
- A a server script that need to know whether the group member is online
in order to IM them with useful or critical notifications in relation to
the group entity, yet not spam them if they are offline. Etc..
One concrete example that this new change is breaking (without the group
based exclusion):
"The Public Sandbox Group" has a group online status device that tracks
registered helpers and show user signs at the entrance to notify who is
online to help with issues. This is currently done without the need to
wear a device and without the need for avatar to be in those sims.(neither
the need to have the group tag active for that matter)
That won't be possible anymore with this new drastic change. It will
require us to have huds that regularly ping server scripts (or the other
way around) instead, to be able to track online status to display the
names/boards accordingly. On top of breaking it, that's a load of
additional work... and not necessarily reducing much load on the sims in
that sense.
Those making a living in SL using such group devices as business tools are
going to scream.