Drop support for old HTTP Engine V1?

Developers forum for Univeral Media Server-related development (only for programmers)
mfulgo
Posts: 10
Joined: Sat Dec 13, 2014 2:59 pm

Drop support for old HTTP Engine V1?

Post by mfulgo »

I'd like to propose dropping support for the old HTTP Engine. I suspect there aren't really any users changing their UMS.conf to not use the default V2.

Technically, it would be a breaking change (so, semantic versioning would say that it needs to wait until version 6.0.0), but I'd like to remove the old code sooner than that. I can rip it out and log an error if the user happens to be using that setting... or we could deprecate it first, give a warning if its used, and rip it out later.

What do you think?
User avatar
SharkHunter
Developer
Posts: 648
Joined: Fri Jun 01, 2012 9:36 pm

Re: Drop support for old HTTP Engine V1?

Post by SharkHunter »

I use v1 :)
We reject: kings, presidents and voting.
We believe in: rough consensus and running code.
nickhere
Posts: 138
Joined: Sat Jan 03, 2015 3:28 am

Re: Drop support for old HTTP Engine V1?

Post by nickhere »

I use v1 :)
somebody old and resistant to upgrade to new and better tec :)
User avatar
SubJunk
Lead Developer
Posts: 3705
Joined: Sun May 27, 2012 4:12 pm

Re: Drop support for old HTTP Engine V1?

Post by SubJunk »

I think I remember that some users had problems with v2 interacting with their renderers so they used v1, ages ago.
nickhere
Posts: 138
Joined: Sat Jan 03, 2015 3:28 am

Re: Drop support for old HTTP Engine V1?

Post by nickhere »

What the latest? What the best for you to use?
User avatar
SubJunk
Lead Developer
Posts: 3705
Joined: Sun May 27, 2012 4:12 pm

Re: Drop support for old HTTP Engine V1?

Post by SubJunk »

I've never changed it from the default (v2) but I've read people saying it has fixed an issue to change to v1, can't remember details.
mfulgo
Posts: 10
Joined: Sat Dec 13, 2014 2:59 pm

Re: Drop support for old HTTP Engine V1?

Post by mfulgo »

I'd be all for fixing whatever the issue is in V2...
User avatar
SubJunk
Lead Developer
Posts: 3705
Joined: Sun May 27, 2012 4:12 pm

Re: Drop support for old HTTP Engine V1?

Post by SubJunk »

I have a feeling the issue was on the old PS3 Media Server forums, and may have been a dead end anyway; users often change 5 settings at once and it fixes the issue and then they attribute the fix to the wrong setting. Who knows.

Why do you use v1, SharkHunter?
User avatar
SharkHunter
Developer
Posts: 648
Joined: Fri Jun 01, 2012 9:36 pm

Re: Drop support for old HTTP Engine V1?

Post by SharkHunter »

SubJunk wrote:I have a feeling the issue was on the old PS3 Media Server forums, and may have been a dead end anyway; users often change 5 settings at once and it fixes the issue and then they attribute the fix to the wrong setting. Who knows.

Why do you use v1, SharkHunter?
Sometime back in the days I had an issue (speed,start delay or whatever) with V2 so I changed to v1 and then never changed back.
What is the reason for removing it? As long as you don't change the APIs that are used from Request(v1|v2) towards the rest of UMS it really doesn't matter right? If you change those APIs we'll have other (bigger) problems...
We reject: kings, presidents and voting.
We believe in: rough consensus and running code.
mfulgo
Posts: 10
Joined: Sat Dec 13, 2014 2:59 pm

Re: Drop support for old HTTP Engine V1?

Post by mfulgo »

If you change those APIs we'll have other (bigger) problems...
I'm not sure why that would be, as long as I were to change everywhere that's calling into them, but that's off topic.

As for the issue you had with V2, it's quite possible that it's resolved with the switch to Netty 4; when I did that, I noticed some definite improvements in memory usage and the lack of the delayed streaming bug that made me investigate switching to 4 in the first place.

But, yes, you are correct. It doesn't really matter. I'm just trying to clean up the code base as much as possible; lines of code directly correlates to bug count, and if we can phase out features that are unused or have (better) replacements, that makes it easier to reason about what the program is doing.
Post Reply