Dolphin Linden

Thanks for taking the time (and not being afraid to make changes)!

Best recommendation I can offer is to make a feature request through JIRA. Any new functionality, Experience Tools related or not, will have to go through normal channels.

The data store treats it as a binary blob of data, so it should be safe to use anything.

Search is something we would definitely like to support, but there are heavy considerations to how we can make it useable, but protect different experiences from interfering with eachother due to long running queries.

llAttachToAvatar detaching is a bug, it is not inteded to auto detach. This was introduced fairly late in the cycle while working on a long standing bug which caused attachments to be ghosted on some people's viewers if they detached during a region crossing event. We are working on getting a fix through the sim pipeline.

I am a little confused as to what behavior is in question here. Can you give me a little bit more explanation? The thing that is really missing, in my opinion, is a parcel changed event, so you can know when to try to re-request permissions. As it stands, the only thing you can really do is periodically check to see if you have changed parcels, and then re-request permissions then.

That would be a bug The intent is that an unchecked update will create keys which do not exist.

That looks pretty yucky Unfortunately I have nothing in the way of helpful suggestions.

Currently, the only action you can take is you disable the Experience (the setting is available on the profile editing page). This can be used for shutting down the Experience temporarily for damage control or other reasons, but there isn't any way to find or get rid of bad scripts after they are out there.

Let's say, hypothetically, you end up with a rogue contributor who makes a bunch of abusive scripts for your experience.  Is there any way to do damage control for something like that?  Or once those scripts are out are you doomed and you need to reset your experience?

The other side of the coin is that restrictions can always be lessened or removed. Adding them or tightening them however is very hard to do without making people angry, even if they themselves are not personally affected. The experience db is a new feature that will have to be evaluated in an ongoing manner. Changing the limits is easy, but making the decision to do so is complex as the effects it has on a large, (nearly) always-on, distributed system must be considered.

The real problem here is that there is no way for the sim to determine the scripter's intent if no experience is sent with a script when it is compiled. Do they mean remove the experience or do they want to keep it the same? Making one decision over the other will incovienience different people. It is also an intentional decision to fail to save a script if you try to use an experience you do not have rights to. With your suggestion, in this case the script could not be saved by someone not in the experience and there would be no way for them to fix it (i.e. they could not change or remove the experience even if they had modify rights on the script). I cannot speak to the schedules of the TPVs but the script signing is not terribly detailed (one call to get a list of ids and then you put one of those ids in the save request).

1) Is defintely a governance issue. 2) You will want to separate experiences where it makes sense. One is to limit the fallout for an AR, but also to keep people from being confused about what they are participating in. 3) Yes

We have a fix for this. it should be in the next update.

While I agree with the sentiment, but I have a different view on the roles. In this case Linden is more like Amazon Web Services and the experience owner is the MMO developer. If an MMO developer wishes to retain content for old users they need to manage the data and pay for the storage.