What are TPV devs saying about the new Policy

[WhiteStar Magic]

This Post is for TPV Developer's to chime in for links to their forums/wiki's where they make a statement of what their take is on the new TPV Policy. 

 

Please let's not turn this into a Drama Post, it is intended to help people locate and reference what the TPV developer's are thinking & saying.

 

For an excellent "Drama Free" clear & concise review of what the TPV Policy means to TPV Developer Henri Beauchamps of Cool VL Viewer who wrote up an excellent review.  It's without postulation & theories, just simply the facts.

see his take on it here:  http://sldev.free.fr/forum/viewtopic.php?f=5&t=741





[Linda Brynner]

What i noticed is that the Phoenix/Firestorm explains it all rather well.

http://www.phoenixviewer.com/

There is nothing more to it as far as i can see.

[Ayesha Askham]

@WhiteStar

As ever Henri is on the money with that post.  It is a pity that more folk in SL don't have Henri's grasp of matters.  Judging from some of the comments made at Oz's presentation (if it can be called that), it is clear that there is still a deal of resentment at Phoenix/Firestorm from Emerald days.

[Baloo Uriza]

Thanks for that post.  Though not sure RLV would really count as affecting the shared experience, since those who don't opt into it aren't adversely affected or have comparatively reduced functionality in the shared space.  I think it's more likely to affect things like the Emerald-specific attachment points and other tricks that don't look right in viewers that don't implement that same hack.  If I'm correct on this, then I'm thankful for that clause.

[Baloo Uriza]

I don't agree about what they're saying about 2k breaking innovation.  TPV devs are still welcome to create new viewer functionality.  But when they do, they have to check it in upstream first so everyone has the same level playing field.  This is a Good Thing.  Why the Phoenix devs are spinning it as evil is anyone's guess.

[WhiteStar Magic]

" I think it's more likely to affect things like the Emerald-specific attachment points and other tricks that don't look right in viewers that don't implement that same hack.  If I'm correct on this, then I'm thankful for that clause."

Your on the right track there Baloo.   It is all about not adding something to one viewer / viewer family that will affect how things are seen by other viewers without that particular "enhancement" and the attachment example is a perfect example of what is good for one but messes up another.  Whether or not a viewer supports an extra function or capability that would have no negative effect on the users of another viewer, as an example, Imprudence supports the LightShare capabilities in OpenSim but supporting that capability has absolutely no impact on SL Grid or any other viewers in use on any grid.  I guess one way to put that, is that is is a "neutral capability & function",  meaning that it does not adversely affect any other.

[Baloo Uriza]

---

WhiteStar Magic wrote:

" I think it's more likely to affect things like the Emerald-specific attachment points and other tricks that don't look right in viewers that don't implement that same hack.  If I'm correct on this, then I'm thankful for that clause."

Your on the right track there Baloo.   It is all about not adding something to one viewer / viewer family that will affect how things are seen by other viewers without that particular "enhancement" and the attachment example is a perfect example of what is good for one but messes up another.

---

OK, well, that just makes Pheonix' team's reaction all the more derpy and irresponsible.  Would have been nice if they thought that response through before posting it.

---

WhiteStar Magic wrote:

Whether or not a viewer supports an extra function or capability that would have no negative effect on the users of another viewer, as an example, Imprudence supports the LightShare capabilities in OpenSim but supporting that capability has absolutely no impact on SL Grid or any other viewers in use on any grid.  I guess one way to put that, is that is is a "neutral capability & function",  meaning that it does not adversely affect any other.

---

Well, perfect, then.  I don't think anybody should have a problem if viewers extend functionality as long as it's not hosing the way everyone else is able to perceive virtual reality.  Glad to hear I'm not the only one who thinks "Well just use $VIEWER-OF-THE-WEEK instead" is a legitimate answer to issues created by $VIEWER-OF-THE-WEEK.

[Nalates Urriah]

The Firestorm Phoenix team takes a lot of heat. A number of people do not trust them because of their Emerald heritage. And a number of people actively try to harm and defame them. There are rumors someone or a team was griefing their meeting today. I don't know how anyone could know because the regions were so overloaded no one could tell what was going on. I couldn't. So, I don't find the rumor too credible but it would not surprise me.

I can't see where the team deserves anything but appreciation and gratitude. I do think the long term heat and harassment takes it's toll on their attitude. 

Thre also seems to be some friction between the team and the Lab. I think there are personality clashes on both sides. But, both sides seem determined to make things work and cut each other some slack. But, they do get frustrated from time to time say things that let some of the frustration show.

Salt what you hear and read. Given them both their props.

We have several great people in the TPV Dev community. Some have posted their take of the policies on their blogs and web sites. Henri B made an excellent post in his forum. I disagree with a couple of points and challenge a couple of points too. But Henri is one of the great assets in the community. We have several.

You can get a great list of links for TPV sites from Inara Pey's blog: Viewer Round-up: February 27th.

[WhiteStar Magic]

I'd like to clarify something on my part in this discussion.  I have nothing against any TPV viewer, including Phoenix / Firestorm or any other for that matter.  I like everyone else has certain preferred viewers but that is not the issue either.  The only obvious exception are those which are modified for nefarious activities, such as copybot use.   I only used the Multiple attachment points issue from the old Emerald viewer as an example which demonstrates what the policy change is partially trying to prevent. 

 

[Baloo Uriza]

---

Nalates Urriah wrote:

The Firestorm Phoenix team takes a lot of heat. A number of people do not trust them because of their Emerald heritage. And a number of people actively try to harm and defame them. There are rumors someone or a team was griefing their meeting today. I don't know how anyone could know because the regions were so overloaded no one could tell what was going on. I couldn't. So, I don't find the rumor too credible but it would not surprise me.

I can't see where the team deserves anything but appreciation and gratitude. I do think the long term heat and harassment takes it's toll on their attitude. 

---

You didn't read their blog post that I was responding to, then.

[Anaiya Arnold]

---

Baloo Uriza wrote:

---

WhiteStar Magic wrote:

" I think it's more likely to affect things like the Emerald-specific attachment points and other tricks that don't look right in viewers that don't implement that same hack.  If I'm correct on this, then I'm thankful for that clause."

Your on the right track there Baloo.   It is all about not adding something to one viewer / viewer family that will affect how things are seen by other viewers without that particular "enhancement" and the attachment example is a perfect example of what is good for one but messes up another.

---

OK, well, that just makes Pheonix' team's reaction all the more derpy and irresponsible.  Would have been nice if they thought that response through before posting it.

---

WhiteStar Magic wrote:

Whether or not a viewer supports an extra function or capability that would have no negative effect on the users of another viewer, as an example, Imprudence supports the LightShare capabilities in OpenSim but supporting that capability has absolutely no impact on SL Grid or any other viewers in use on any grid.  I guess one way to put that, is that is is a "neutral capability & function",  meaning that it does not adversely affect any other.

---

Well, perfect, then.  I don't think anybody should have a problem if viewers extend functionality as long as it's not hosing the way everyone else is able to perceive virtual reality.  Glad to hear I'm not the only one who thinks "Well just use

$VIEWER-OF-THE-WEEK

instead" is a legitimate answer to issues created by

$VIEWER-OF-THE-WEEK

.

---

What's derpy about their response?  What did they not think about?

Just because you think that removing an entire sphere of innovation has no impact on innovation, it does not necessarily follow that someone else must be making derpy and irresponsible responses.

Multiple attachments never bothered me.  It's no skin off my nose if someone else looks bald with a wig floating around their belly button.  If I had to choose between whatever inconvenience or issue that was supposed to be to me, and having multi attachment points, visible to all viewers, in the here and now,  I prefer to have "suffered" the alleged issue.  It never really was an issue to me and I surely do love multi attachment points being standard.

I can see LL's point and I don't necessarily disagree, but it's purile, not to mention derpy, to pretend that this policy change has no negative implications for innovation, or to start accusing people who claim that it does have negative implications for innovation of being derpy and irresponsible for doing so.

Was it you making those derpy, irresponsible and completely untrue claims about the Firestorm dev team not contributing anything back to the main LL code in some other thread?

[Baloo Uriza]

They're claiming that innovation is dead when all that's changing is that they're actually expected to throw patches back upstream for compatibility.  In other words, they're being held to the common courtesy most code forks already do.

[Hitomi Tiponi]

---

Baloo Uriza wrote:

They're claiming that innovation is dead when all that's changing is that they're actually expected to throw patches back upstream for compatibility.  In other words, they're being held to the common courtesy most code forks already do.

---

As far as I know all the TPVs have always been more than happy for LL to incorporate their changes, and have been willing to assist in the incorporation. If LL has a good reason for not implementing a feature (e.g. server load) I am sure that the TPV devs would leave it alone or amend it until LL were happy. The issue here is that if LL does not like that a feature for any reason at all ('not enough staff to implement', 'not our priority', 'we do not think it would be popular') it will not be possible to add it to any third party viewer.

 

 

[Perrie Juran]

---

Baloo Uriza wrote:

They're claiming that innovation is dead when all that's changing is that they're actually expected to throw patches back upstream for compatibility.  In other words, they're being held to the common courtesy most code forks already do.

---

No, they are being asked for more than that.  While yes, compatibility is an issue, LL could turn down a compatible function.  Totally within LL's rights.  SL is their product.  But it is more than just 'compatibility' they are being told to seek approval for. We can only hope that compatibility is the genuine reason for rejecting a new feature.

Oz acknowledged that in the past things were handled poorly by the Lab, hence the skepticism many people have. 

Look at the Lab's resistance to Avatar 2.0.  Prim feet are a big selling item in the market because of how bad feet look in SL.  As one person said, if there was any proof the Avatar was designed by a man, its the feet.  A woman would have never stood for such a travesty.

Technically speaking, the way the policy reads, if I came up with a way to make feet look more natural that only the users of my TPV could see, it would violate the rule because not all users could see it.  Or I could be constrained from adding the feature until the Lab saw fit to add it to the official viewer.

How about the camera controls in the Official Viewers?  You still can not re-size it despite how much people have complained about it.  You can re-size it in the TPV's.  Why not the official viewer?

For what ever personal reasons the TPV Devs may have for doing what they do, whether the reasons are altruistic or selfish, the goal still is to give us all individually a better experience.

 

[Sharie Criss]

LL usually doesn't have a good reason for not incorporating some of the wonderful features that TPV viewers have. As far as server load, since 99.999% of the features don't affect anything server side, that's kind of a red herring. I'm not a firestorm fan for a number of reasons, and not a fan of some of the team personalities, but the fact is that it's the number one viewer because it delivers what people want and LL isn't doing that. LL has a very very long history of ignoring what users want and listening instead to their marketing department's polls of 10 year olds. (I think the 10 year olds designed the Viewer 2 UI - it showed!) When LL ACTUALLY starts listening to residents (and listening means more than JUST hearing) then I'll have a little more respect for their decisions. Some of these decisions, such as breaking scripts that have a VALID need to check online presence due to the total unreliability of offline message and inventory delivery, are just incredibly stupid showing a gross disregard for the huge issue of inventory loss and reliability.

[Baloo Uriza]

---

Hitomi Tiponi wrote:

---

Baloo Uriza wrote:

They're claiming that innovation is dead when all that's changing is that they're actually expected to throw patches back upstream for compatibility.  In other words, they're being held to the common courtesy most code forks already do.

---

As far as I know all the TPVs have always been more than happy for LL to incorporate their changes, and have been willing to assist in the incorporation. If LL has a good reason for not implementing a feature (e.g. server load) I am sure that the TPV devs would leave it alone or amend it until LL were happy. The issue here is that if LL does not like that a feature for any reason at all ('not enough staff to implement', 'not our priority', 'we do not think it would be popular') it will not be possible to add it to any third party viewer.

 

 

---

I mean proactively checking in code.  Not just expecting upstream to be psychic about finding it.

[Baloo Uriza]

---

Perrie Juran wrote:

How about the camera controls in the Official Viewers?  You still can not re-size it despite how much people have complained about it.  You can re-size it in the TPV's.  Why not the official viewer?

 

---

Did anybody bother to submit a patch upstream?  If not, why not?  Why would anybody expect upstream to follow a brazillion different code forks they don't develop?

[WhiteStar Magic]

Marvelous hijacking of a thread... too bad I can't lock it as it's become pretty well useless for it's original intent now....

On the FIRST POST it was written " Please let's not turn this into a Drama Post, it is intended to help people locate and reference what the TPV developer's are thinking & saying."  in bold so it would be noticed but I guess it doesn't apply to those who don't care.



 Why not just start your own msg thread ?  Too simple I suppose.

 

[Anaiya Arnold]

---

Baloo Uriza wrote:

They're claiming that innovation is dead when all that's changing is that they're actually expected to throw patches back upstream for compatibility.  In other words, they're being held to the common courtesy most code forks already do.

---

Er your interpretation is way off base.

 

In the first instance, there is no "not handing" upstream.  They are not allowed to not share the code under the license for LL's code, so anything LL want they can have.  Secondly, it was not true when you claimed it earlier and it's still not true that they do not contribute.

What has changed is that before they could send the patch upstream and LL could use or disregard it, or go digging for anything and everything else they wanted from any TPV forked from LL's code under LL's licensing terms, and if LL did not want it, the TPV could offer it to their own users.  Now if whatever the innovation is happens to effect the shared experience, they can still offer it to LL just like they always could, LL can still just take it if they want it, just like they always could, but the TPV cannot offer it to its own users unless and untill LL put it in a release version of their own viewer.

 

The fact you are glaringly ignoring is that contributions from TPVs including the firestorm team you have some kind of bee in your bonnet over, were already available to LL and that on occassions FireStorm devs worked proactively with LL to ensure a smooth and speedy implementatino of such conributions back "up stream".  At this point, since this fact has been pointed out to you in another thread that you returned to and posted in again, all while ignoing this fact being pointed out to you, it seems like your tall tales are deliberate lies rather than an honest mistake.  Kindly explain what stopped LL from implementing any code they felt like from any TPV compliant viewer before this change?

LL have no more access to TPV code under the new policy than they did under the old.  None, nada, zilch.  Stop making up tall tales Baloo.

[Genn Moderator]

Hi everyone! Just a friendly reminder to stay on the topic of the thread and to refrain from moving off-topic and onto personal insults. Thanks!

[Feldspar Millgrove]

---

Baloo Uriza wrote:

TPV devs are still welcome to create new viewer functionality.  But when they do, they have to check it in upstream first so everyone has the same level playing field.

---

This is emphatically incorrect, according to everything Oz Linden said at the meeting.

They are not welcome to create new functionality in general.  Note that we're talking about "shared experience" features here.

And it has nothing to do with "checking in the feature upstream (to LL's code)."  What LL has said at the meeting is that (a) LL must create the feature (b) LL must roll out the feature in the released version of the Official Viewer © After that, TPVs may have the feature also.

If someone wants to create a new feature for their TPV, they are not allowed to do so.   What they must do is contact Linden Lab and see if they can get someone's attention there.  They may requrest that Linden Lab put the feature in. The third party developer may offer suggestions or code, but this not about "checking in" code or directly contributing to the Viewer.  If LL is interested in the feature, LL will take it under advisement and  might eventually someday devote resources to developing the feature as they see it.  And then LL might eventually roll it out to the Official Viewer.  After all that happens -- if it happens at all -- then the TPV may include the feature, as long as it's the same as what LL already released.