Developers: breaking changes forthcoming in 1.50.0

Announcements about PS3 Media Server

Re: Developers: breaking changes forthcoming in 1.50.0

Postby Raptor399 » Mon Oct 17, 2011 7:52 pm

renszarv wrote:Unfortunately it's not possible, because we can get more information with the new method, because the old one haven't received the end of the time range, so we can call the old one, from the new, but not the otherwise.

Huh? That is strange.

Let's assume I'm a plugin writer (I'm not ;-)).
My current code reads:
Code: Select all
InputStream is = resource.getInputStream(a, b, c, config);

This will be deprecated in 1.50, so now I want to migrate my code to the new method signature.
How do you suggest I rewrite my plugin code?
Raptor399
Project Member
 
Posts: 1916
Joined: Thu Mar 10, 2011 12:06 am

Re: Developers: breaking changes forthcoming in 1.50.0

Postby renszarv » Mon Oct 17, 2011 9:45 pm

Raptor399 wrote:
renszarv wrote:Unfortunately it's not possible, because we can get more information with the new method, because the old one haven't received the end of the time range, so we can call the old one, from the new, but not the otherwise.

Huh? That is strange.

Let's assume I'm a plugin writer (I'm not ;-)).
My current code reads:
Code: Select all
InputStream is = resource.getInputStream(a, b, c, config);

This will be deprecated in 1.50, so now I want to migrate my code to the new method signature.
How do you suggest I rewrite my plugin code?



Why strange ?
The old code is like :
Code: Select all
InputStream is = resource.getInputStream(a, b, c, config);


The new code is like:
Code: Select all
InputStream is = resource.getInputStream(a, b, c, d, config);


With the additional contraint that either a - b or c - d is specified, at most. Just the Range class encapulates either a byte-range, or a time-range.
So if you are a plugin developer, and you don't care about seeking, you don't have to do anything :) If you only support byte-range based seeking, you should check for Range.Byte and handle the case ... or if it is able to handle Range.Time, check for that, and handle separately.
renszarv
Project Member
 
Posts: 105
Joined: Sun Aug 21, 2011 7:37 pm

Re: Developers: breaking changes forthcoming in 1.50.0

Postby SharkHunter » Tue Oct 18, 2011 7:58 am

I'm with raptor here. Thats what I want. The reason is simple. If I need to fix a bug in a plugin now I'll have to keep track of which PMS I'm building towards etc. There are people who find this kind of logistics funny, I don't, I like the code. For that reason both signatures should be present for a transient time. The old sig should call the new just like raptor suggested, and yes it is of course possible to do that. And since constructs of this
Code: Select all
long low = range.isByteRange() && range.isStartOffsetAvailable() ? range.asByteRange().getStart() : 0;
                long high = range.isByteRange() && range.isEndLimitAvailable() ? range.asByteRange().getEnd() : -1;

is in the new code I find it really hard to believe it is impossible to do a function that creates a range out of the 3 int/doubles? Yes the functionallity will not be as good as it can be with the new method BUT it will not be worse than it was before. If no backwards compatible function is made the plugin will not work at all which is way worse than it was before.

Making changes to really core stuff like DLNAResource should in my opinion always be made 100% backwards compatible for 2-3 releases and maybe even ask on the forum if anybody is affected in a negative way by this change. It might be that the thing you like to change requires a complete rewrite of something.
SharkHunter
 
Posts: 941
Joined: Tue Jun 01, 2010 8:39 pm

Re: Developers: breaking changes forthcoming in 1.50.0

Postby Raptor399 » Sun Oct 30, 2011 10:11 pm

To add to the list of breaking changes:

  • Old occurences of DLNAResource.getId() should be replaced by the new method DLNAResource.getResourceId()

The old getId() would return something like "0$0$1$3", the new getId() returns the internal id of the resource, which is something like "3" (without parents). The newly introduced getResourceId() mimics the pre-1.50.0 getId() behavior.

We would like to make all DLNAResource instance variables private, so r962 introduces proper getters and setters for all protected variables. Please use these access methods.
The variables have been left as is to remain backwards compatible, but they will be made private in the future.

To help you find affected plugin code, all protected variables have been marked with @deprecated.
Raptor399
Project Member
 
Posts: 1916
Joined: Thu Mar 10, 2011 12:06 am

Re: Developers: breaking changes forthcoming in 1.50.0

Postby Raptor399 » Sat Nov 05, 2011 1:16 pm

A minor breaking change is introduced in r968:

  • Old occurrences of DLNAMediaLang.getLang() should be replaced by the new method DLNAMediaLang.getLangFullName().

The old getLang() would return something like "Undetermined", the net getLang() will return the language code instead, something like "und". The newly introduced getLangFullName() mimics the pre-1.50.0 getLang() behavior.
Raptor399
Project Member
 
Posts: 1916
Joined: Thu Mar 10, 2011 12:06 am

Previous

Return to Announcements

Who is online

Users browsing this forum: No registered users and 11 guests