Stopping the divergence between RLV and RLVa
Issue #72
new
Something needs to be done to prevent the increasing divergence of RLVa from the RLV spec, ideally a unification of code and specification into one so that we don't end up with two divergent systems where developers have to choose which to support (eg Lockmeister/Lockguard all over again).
Amongst the differences I know about...
- blacklist not in RLVa
- RLVa attempts to restore environment settings on setenv=y
- RLVa doesn't implement touchfar, only fartouch
- RLVa has commands not in the specification like touchhud
This is teetering on the edge of a cliff... action is needed now for unification! Devices are appearing which rely on RLVa behaviour, not the specification.
Yes, I sound alarmist here, but I really really don't want yet another Lockmeister/Lockguard situation to deal with as a protocol user.
Comments (15)
-
repo owner
-
reporter
Agreed in all respects. This issue, unlike
#71, is more fundamental and philosophical - what can be done at a personal level to bring unification about?If the answer is more finger pointing back and forth we as developers can resign ourselves to having to write toys that work with RLV and RLVa separately.
Unless there's a positive effort to bring unification to pass, this divergence will just continue unabated.
-
repo owner
The purpose of RLVa is to test commands that are not included in the spec, while providing all the commands that are included, so it is compliant, but has a few commands that are not specified. This is normal and these commands should never be taken as being canon by the scripters.
The particular case of @touchfar was added to keep consistent with the other @touch* commands, but I agree @fartouch is much older and @touchfar has no real purpose other than that. But now that it's there, RLVa should include it as well.
As for @touchhud, I got so much flak thrown at me when I added the @touch* commands that I gave up trying to implement it. Maybe later since it doesn't seem to disturb Kitty.
In any case, you have noticed that my RLV has been in standby for months. This was due to LL not fixing several blocker bugs in their v-d branch and apparently not caring, they seem to have fixed them only last week. I'll slowly get back on coding on the RLV but frankly this last version of the SL viewer has been a great demotivator for me. That's why I had put it on the back burner lately and moved to other more rewarding projects.
So when we have once again a working codebase that is more fun than work to tweak and experiment on, I'll get back to it. For now it's just frustrating.
-
reporter
I hear the frustration... :)
Last comment from me coming up - it's a long way from being as simple as RLVa == RLV + experimental code.
As I pointed out above, @setenv=y behaves differently between RLV and RLVa, RLVa doesn't implement the blacklist and associated commands, it doesn't have the @touchfar synonym - it's not a complete implementation of RLV plus extra bits, it's a divergent implementation now.
There are commands in RLV not in RLVa. There are commands in RLVa not in RLV. When commands are in both, sometimes they behave differently.
(Agreed that touchhud will be an emotive one, but that's where the blacklist comes in!)
I'll leave it here now :)
-
repo owner
Well to me @setenv=y should not make the environment settings back to default, that is the role of @setenv_daytime:-1.0=force.
As for the blacklist, I find this a little hard. I have added the blacklist to the spec and implemented it after discussing with people like Kitty, and at first I was against it. In my point of view, there is no such thing as a "half RLV" due to having some commands blocked, but I'm not the only person on earth. Now, if one command should be implemented in RLVa, that would be this one because it came from the RLVa people in the first place.
Same for @touchfar actually. I did not want to add the @touch* commands at first because most of them could be done through a script, and some of my business actually did just that. By adding those commands I hurt my own business. Now they're out and used broadly, and in the spec.
I'll talk to Kitty and point her to this page so she can give her point of view as well. I suspect she is just like me : she has given up on the LL code base for the last few months because it is completely rotten.
-
Ok .. First up the purpose is RLVa is not to test things for anyone or any purpose. It's in an independent implementation of the specification. It shares common interpretation of the specification written by Marine, and nothing more.
The RLVa implementation is entirely subject to the interpretations of those responsible for actually implementing it.
If you wish to talk about RLVa, then might I also suggest you come talk to the afore mentioned responsible people directly (that would be Kitty and myself, who is sat 2 feet from me off screen).
On the specific points listed (non of which constitute a breaking change, bugs will always be fixed).
The blacklist as proposed will never be added to RLVa, it's arbitrary, hacky and completely unfriendly to both end users, developers and those interacting with RLV enabled attachments and objects. We are firmly of the position that the blacklist simply breaks content in the worse possible ways. We are working out details of an alternative system for handling consent.
Variations in command interpretation in RLVa will always lean towards a user friendly position when we have the option. An example would be if an attachment uses renderresolutiondivisor along with windlight to obscure vision, RLV will keep this setting between viewer sessions, RLVa wont. As Second Life clients tend to crash from time to time this would seem like a good idea.
By the same token @setenv=y will restore windlight to the user previous settings (whatever they might have been), rather than leaving the user blind or forcing it back to noon - neither of which could be called user friendly.
@farrouch @touchfar is an oversight, it will be fixed in 1.5 .. kind of a moot point when half the user base is still on Phoenix with RLVa 1.1ish something.
RLVa has commands RLV doesn't. We are never going to hold back on development and are working up towards adding some significant new work to RLVa, new commands will be more distinct to prevent overlap with RLV. If Marine chooses to implement these new commands in RLV herself then we will of course support that.
RLVa development has been held back due to the user base remaining on Phoenix (etc), this situation is changing with more users switching to V3 based RLVa viewers.
-
reporter
And there we have it... now try telling me that there isn't a problem with two divergent versions which is getting worse by the minute.
-
There isn't a problem. If you want to have a storm in a teacup and play politics with an issue no one has an issue with go right ahead.
-
reporter
There is a problem.
Trinity's first reply makes it clear that Kitty and she do not consider that RLVa exists as another implementation of the RLV specification, but rather an independent vehicle choosing to innovate the RLV specification in some ways, improve it in others and ignore it in some cases.
I'm trying not to take sides here, as a developer there is a specification of the interface and two implementations. These two implementations are increasingly diverging. That is creating a more and more difficult position for developers - I know some will choose to adhere to RLVa's implementation and eventually tell people that their products won't work with Marine's RLV implementation but personally I aim to implement against the specification and expect whichever implementation is being used to accurately and wholly support the specification.
The issue is that RLVa now has a life and a purpose and an agenda of its own. I'm not saying that's bad, and not saying that RLVa is evil and Marine's RLV implementation is good. What I believe we need is less pointing fingers, more working together, and less polarised immovable positions as I've succeeded in demonstrating here.
Lockmeister and Lockguard, here we go again...
-
Yes. RLVa is independent from RLV. We are committed to maintaining a compatibility with the spirit of Marines RLV specification at the very least.
You are quite plainly attempting to pick sides and cause conflict where there is none, the only person pointing fingers here is yourself.
If you are suggesting that either ourselves or Marine should forgo development or the ability to spend our spare time doing what we choose from the sidelines, then you are seriously mistaken. (Especially as unlike yourself or Marine, we do not have a vested commercial interest to protect).
We are on the side of the larger community.
We work very closely with the majority of product developers and end users alike to ensure that behaviour is as expected and desired. That means we literally work with product developers, own a considerable stock of items and are proactive in engaging with the wider user base.
We spend a lot of time with all the other TPV projects ensuring that a consistent experience is presented regardless of platform. Your own RLV based products work as expected on Firestorm, Phoenix, Singularity, Exodus and our own Catznip to name but a few. You're welcome, and with ZERO commercial gain on our part.
On the point of Lockmeister and Lockguard .. The similarity ends at the word Lock. Lockguard was designed from the outset to be a developer friendly alternative to Lockmeister, which was at the time, very exclusive. The world did not end. More products had particle chains.
-
reporter
What I'm suggesting, revolutionary as it might sound, is the opposite of taking sides -- that has already happened, and is how we get to today's situation with different implementations that are set to continue diverging.
What I believe should happen, though I doesn't look like anyone's likely to take it seriously, is a common effort to unify the specification to reach something that every implementation team can believe in and adhere to, and maybe even just one implementation of that specification so that everyone can get an identical experience.
-
Development is entirely separate, RLVa shares no code with RLV, they can't even be somehow magically combined at that level. Their are significant differences that go beyond @this doing exactly @that because @someone @said @so. The differences between commands from a scripters perspective is the trivial part.
For example (and this is just the first that comes to mind) attachment locking is handled significantly differently; RLVa does not require attachments to have folders or names containing (spine) or (face) or whatever - even in shared inventory. RLVa will never pop a locked attachment off when you add another to the same point.
The only solution to this OCD-esque problem is RLV and RLVa stop being separate. Which presumes that either party are willing to give up writing code, control of our own efforts or both.
-
repo owner
I don't think the differences in implementation are an issue for the scripters. There are things that RLVa does that RLV does not do, and vice-versa, but that doesn't impact the spec. As for the blacklist, I've had my hand forced on it and never wanted it in the first place. But now that it's there, I can't remove it anymore since it has several RLV commands tied to it. And there is no question of merging both codes or either developers giving up writing code because of the differences. I said last year that I wanted to merge into RLVa, but after looking deeply into both, it quickly occurred to me that it was impossible. And several developers rely on my RLV to make their viewers work, so no question of me giving up my work.
So I am afraid things will stay as they are now. I did not decide to make a completely different implementation, which exists because I was refusing to take patches at the time (it has nothing to do with the first version of my license, which came later). I was refusing to take patches because I had taken a few already from people I thought were competent, and the patches revealed to be bugged, badly designed and untested. And all the work went on my shoulders, as usual. That pissed off a few people, and that's how RLVa was born.
Now, I don't care about those differences. As long as RLVa implements the spec and the scripters don't have to wonder whether they are talking to a RLV or a RLVa, it's all good. I want to avoid another Lockmeister/Lockguard fiasco and so far we're not there yet and I don't think anyone wants to go there anyway. It's not a matter of vested business interests either, I'm also doing this for free and the time I spent working on the RLV, I didn't spend it working on my products.
-
Account Deleted
Well I've had chats with both Kitty and Marine (mostly Kitty) on differences, In all but one case Kitty has changed RLVa to confirm to the specification. I find her very approachable and she tries hard to meet the spec.
The one case she did hold out was on the debug settings and to to honest her logic made sense,
Debug settings should not persist across log in sessions, at least until relays catch up, it a pain to support people that cheated out and are now blind.
And it should be trivial to re-introduce the restriction on log in
-
repo owner
"Debug settings should not persist across log in sessions"
Most do, those that should not are flagged "persistent = 0". However "it should be trivial to re-introduce the restriction on log in" depends on the individual scripter. This means that if I were to set RenderResolutionDivisor to non-persistent (which is the issue here), some scripters may scream because their products would break on relog. I am not against making it non-persistent, I understand it is confusing for newbies to be blind on relog despite having no relay and not even being on a RLV, but it might be dangerous.
It might be worth a try, though, because since Kitty makes it non-persistent I guess people are already used to having it non-persistent.
- Log in to comment
@touchfar and @fartouch are synonyms, RLVa should implement them
@touchhud is not in the spec, maybe I can add it later.
It is not because RLVa implements a command that is must automatically be in the spec. It must be discussed first.