• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-3245
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: Darien Caldwell
Votes: 16
Watchers: 10
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

http-in beta: Give Landowners the ability to see URL allocation for their parcel.

Created: 15/Oct/08 01:30 PM   Updated: 18/Mar/09 05:47 AM
Return to search
Issue 1489 of 2056 issue(s)
<< Previous | SVC-3245 | Next >>
Component/s: None
Affects Version/s: 1.23.0
Fix Version/s: None

Issue Links:
Relates
 


 Description  « Hide
Under the "Objects" pane of the About Land floater, you can see a list of who has objects rezzed on your land, and how may prims they have rezzed. It would be nice to add another column, showing how many URLs they have allocated.

I don't see that adding this would be too much of a hardship, as most of the framework is already in place, just a new column in the data field. ;p And I think it would be of great use to landowners to both administer and diagnose possible issues that come up with URL allocation.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
baron nowhere added a comment - 15/Oct/08 03:41 PM
This may be a good time to combine this effort with http://jira.secondlife.com/browse/SVC-835 – the SVC-835 is a request to allow land owners to see the script runtime.

I agree with providing any tool we can to help owners identify sources of lag on their land.


Ann Otoole added a comment - 18/Oct/08 09:43 AM - edited
How about a separate option flag to allow/disallow these type devices unless in the group or owner at both parcel and region level?

I.e.; can drop a box to open it for a minute but not if that box has URLS. I.e.; the entire primitive that supports http be a separate primitive type that can be selectively allowed, by individual, group, parcel, and region level permissions.

I don't want anyone but me dropping URLs in my region ever. Not ever. Not after reading how it will certainly be abused.

It is bad enough they come in wearing stuff that communicates with the outside world to scan and catalog the sim contents without permission.
Now they can come in and dump a zillion url's to their stores.
Nice move.

LL needs to be thinking about how selfish people think when considering new features and implement ways to prevent bad behavior before it is released.

Banning after it happens? it will keep happening over and over, and you know it will, until the gray goo fence style coding is in place so may as well code it in from the outset.


Darien Caldwell added a comment - 18/Oct/08 02:34 PM
Ann I think you got the wrong impression of what the URLs are. They are simply URLs that provide access to the prim's script data from the outside world (the internet). A sample URL would be: http://sim123.agni/cap/f23b4b94-012d-44f2-bd0c-16c328321221

This URL is only provided to the script. and then the script can send it to whatever service needs to know and gain access to the prim. What people have a concern about are people using a script to allocate all the URLs and somehow prevent them from using services that would need those URLs to function. Using no build or autoreturn is a simple and effective way to preven this. However to be more proactive, it would be good for a paracel owner to see that, say, the cube a visitor rezzed is using 75 URLs for no good reason, and then they could return it. Or at the very least, ask them why they need 75 URLs, assuming it was even blocking their service. I expect most portable applications will use the 38 personal URLS anyway, which does not affect the parcel limit.

It certainly couldn't be used to advertise a store.


Vampaerus Wysznik added a comment - 18/Mar/09 05:47 AM
The evolution of the new functionality is described more in SVC-1086. Intentional abuse of other's sim resources has already been addressed in the way vehicles are handled. There is still a small possibility of abuse (overuse) of LL resources in general. Tho the more likely problem is unintentional misuse and poor tracking of resource allocation. This suggestion (SVC-3245) would be a good counter-measure for accidental URL waste.