Breaking changes ? (PMS 2.0 ?)

[renszarv]

Hi,

I understood that breaking changes shouldn't go into a point release, but as I dived into the code in the last couple of months I saw a lot's of possibility where the code quality can be improved, which wont add any new shine feature, just helps the poor grumpy developers - like me - to understand what's happening around. I know, lot's of other people have contributed to this project for a very long time, so I would like to know what others think about the project, and what plans do you have ? Because there are lot's of independent development happens around, in plugins, or in custom forks, it's not easy to see what feature do we like to implement, what goals we like to reach.
Currently I have the following list in my head, which are worth considering :

• modularization (or mavenization too)- I know there were some experimental forks where it's implemented. What were the conclusions ? Is there some opposition against ? I think it would be beneficial if we can separate into modules the 'plugin interfaces', the 'core' (which handles the configuration, media library, the folder hierarchy), the 'renderer/player', the 'http server', the 'Swing UI', the 'windows/linux/osx specific code', and the 'plugins'
• migration to a distributed version control system - I'm sure this would help the life of the contributors, and plugin developers. Easy forking and merging streamline the development.
• I consider very bad style, when a class has public instance variables, I would like to eliminate all.
• for me it seems that the DNLAResource contains too much functionality, after my refactorings it still nearly 1500 lines, and have ~30 instance variables. And it still contains code like if (this instanceof RealFile) ..., which is the very opposite what 'object orientation' and good practice should mean, for me, at least So I like to refactor the code, to have a much simpler ancestor objects, which only defines the basic functionalities (like getChildren / discoverChildren / searchByID / etc ), and the descendant objects can add custom functionalities, and not need to suppress inherited functionalities.
• some media library functionality I consider is essential - I would like to see pms-mlx code merged, especially I like it's nice UI for managing the media hierarchy
• I would like to have a full featured http interface for managing the server, it would help the headless installation too.

Any other ideas, plans ? And contributors to help implement these ?
I don't want to force anyone to work on my plan in the next decade Just I want to know, that the other devs think. If noone is interested to cooperate, I will implement which I see it absolutly minimum for my peace of mind

[taconaut]

Hey,
I'm going to comment on your remarks in my name only I'd be curious to hear from the other devs as well.
First off, thanks for contributing; I've skimmed through some of your patches and they look interesting.

modularization (or mavenization too)- I know there were some experimental forks where it's implemented. What were the conclusions ? Is there some opposition against ? I think it would be beneficial if we can separate into modules the 'plugin interfaces', the 'core' (which handles the configuration, media library, the folder hierarchy), the 'renderer/player', the 'http server', the 'Swing UI', the 'windows/linux/osx specific code', and the 'plugins'

I'm all in favour to mavenize it, but won't do the work due to a lack of knowledge.
Braking up the code in different modules would be nice, but is quite a lot of work. I've been tinkering with the idea to remove all UI code (which is tightly coupled to the business) from the application and expose functionalities through web services. Got a little project starting the concept under pms-remote. Exposing the configuration is trivial for most parts (exposing methods from PmsConfiguration); some problems remain, as the engines (mencoder etc) are getting loaded asynchronously and dynamically and plugins can be configured through a GUI (swing) as well.
I don't think the http server should be a part of the default installer but rather a plugin that can be added.

migration to a distributed version control system - I'm sure this would help the life of the contributors, and plugin developers. Easy forking and merging streamline the development.

I'm fine with svn, haven't used git yet though.

I consider very bad style, when a class has public instance variables, I would like to eliminate all.

Agreed

for me it seems that the DNLAResource contains too much functionality, after my refactorings it still nearly 1500 lines, and have ~30 instance variables. And it still contains code like if (this instanceof RealFile) ..., which is the very opposite what 'object orientation' and good practice should mean, for me, at least So I like to refactor the code, to have a much simpler ancestor objects, which only defines the basic functionalities (like getChildren / discoverChildren / searchByID / etc ), and the descendant objects can add custom functionalities, and not need to suppress inherited functionalities.

Haven't worked enough with it to juge how it could be split up. Had to workaround some behaviours with pms-mlx though.

some media library functionality I consider is essential - I would like to see pms-mlx code merged, especially I like it's nice UI for managing the media hierarchy

Thanks Agreed, but there's still lots of work to do before it can be added to the offical build.

I would like to have a full featured http interface for managing the server, it would help the headless installation too.

As said above, I'd rather have it as an optional plugin. Anybody wanting to start development has everything at his disposal.

[lightglitch]

I did some of those suggestions (and some more radical like a complete core rewrite) a while a go to the main developers and I'm willing to contribute.

[renszarv]

Hey,
I'm going to comment on your remarks in my name only I'd be curious to hear from the other devs as well.
First off, thanks for contributing; I've skimmed through some of your patches and they look interesting.

Thanks !

modularization (or mavenization too)- I know there were some experimental forks where it's implemented. What were the conclusions ? Is there some opposition against ? I think it would be beneficial if we can separate into modules the 'plugin interfaces', the 'core' (which handles the configuration, media library, the folder hierarchy), the 'renderer/player', the 'http server', the 'Swing UI', the 'windows/linux/osx specific code', and the 'plugins'

I'm all in favour to mavenize it, but won't do the work due to a lack of knowledge.
Braking up the code in different modules would be nice, but is quite a lot of work. I've been tinkering with the idea to remove all UI code (which is tightly coupled to the business) from the application and expose functionalities through web services. Got a little project starting the concept under pms-remote. Exposing the configuration is trivial for most parts (exposing methods from PmsConfiguration); some problems remain, as the engines (mencoder etc) are getting loaded asynchronously and dynamically and plugins can be configured through a GUI (swing) as well.
I don't think the http server should be a part of the default installer but rather a plugin that can be added.

Yes, I agree with you. Code restructuring is quite a lot of work. I've seen a mavenized PMS, someone already done it, but it seemed abandoned (which I can understand totally - applying changes to a restructured code base is not, what anyone want to do for a long time ) I know that the UI is closely linked to the core - for example the renderer configurations, etc - so that too is not so simple to achieve. But fortunately the code base is not soo big
I'm always very suprised that this soo many forks, and plugins already exists for PMS, for example your pms-remote I can imagine what type of problems have you encountered trying to implement it.

migration to a distributed version control system - I'm sure this would help the life of the contributors, and plugin developers. Easy forking and merging streamline the development.

I'm fine with svn, haven't used git yet though.

I think it has a couple of benefits over svn. Merging or picking some change sets from other branchs is lightning fast, and easy. Not to mention, that it's much simpler keeping track of an 'upstream' project with rebasing the changesets against newer versions. Currently I'm trying to keep track a couple of forks made by others on github, based on lightglitch repo (at https://github.com/gzsombor/ps3mediaserver/network ), so at later stage it will be easier to merge/combine if it's needed.

for me it seems that the DNLAResource contains too much functionality, after my refactorings it still nearly 1500 lines, and have ~30 instance variables. And it still contains code like if (this instanceof RealFile) ..., which is the very opposite what 'object orientation' and good practice should mean, for me, at least So I like to refactor the code, to have a much simpler ancestor objects, which only defines the basic functionalities (like getChildren / discoverChildren / searchByID / etc ), and the descendant objects can add custom functionalities, and not need to suppress inherited functionalities.

Haven't worked enough with it to juge how it could be split up. Had to workaround some behaviours with pms-mlx though.

Unfortunately I'm still doesn't understand at least half of the variables of that class

some media library functionality I consider is essential - I would like to see pms-mlx code merged, especially I like it's nice UI for managing the media hierarchy

Thanks Agreed, but there's still lots of work to do before it can be added to the offical build.

I know that creating a useful media library is not easy, because I guess, every one store their movie collection in an unique hierarchy, so you have to guess, that how to collect as much information as possible from the full path, the file names, to get the name of the movie (detect if it's a tv series, then interpret the names a little bit different) ... , and after how to group together one-or-more video file with one-or-more subtitle file, or with an nfo-file, or with a cover.jpeg, or with a sample, etc ... And after you know the title, and a list of related files you need metadata ... from IMDB .. and TMDb ... and your local movie site ... and you have to merge the various informations together ... So it's not an easy process, and not an easily automatized process. I know that, because once, I've already tried it, in the Flicklib project : http://code.google.com/p/flicklib/

I did some of those suggestions (and some more radical like a complete core rewrite) a while a go to the main developers and I'm willing to contribute.

I'm interested, what do you think, what do you want to rewrite in the core Or, if everything, then I'm more interested, how do you think ?

[SubJunk]

Personally I don't care much how the code is written other than basic things like indentation for the sake of readability. As long as it works and isn't noticeably slow I would rather focus on improving on the purpose of the program (file compatibility, features, etc.)
However of course you are free to make the code better if that's what you would rather do, I'm just speaking for myself

[SharkHunter]

I'm with SubJunk here. I want more features (and that's what I do in the SHBs add all kind of weird stuff). Rewriting code just for the sake of it is probably going to cost more than you gain (in terms of new bugs etc.).

[lightglitch]

Personally I don't care much how the code is written other than basic things like indentation for the sake of readability. As long as it works and isn't noticeably slow I would rather focus on improving on the purpose of the program (file compatibility, features, etc.)
However of course you are free to make the code better if that's what you would rather do, I'm just speaking for myself

For me improving the code is a way to make it easy to extend pms with new features.
If the code it's easier to understand more developers will contribute because understanding a class with 1500 lines it's a pain.

[taconaut]

Having code which is properly structured is definitely easier to maintain and will improve code quality. In the short run, changing the structure would probably add some side effects and bugs, in the long run it would probably be beneficial to the project. If this should happen I think it would be best to start off with defining the concepts with different types of diagrams which should then be respected. I still think it would be a good thing to do, but as Subjunk and SharkHunter said, there are plenty of features which could still be added rather then changing things the end-user won't even notice. I'll stick with small changes in the pms base code and will continue working on the media library in mlx (hopefully soon... haven't touched the code for months now).

[renszarv]

I always think about refactoring is not about introducing new bugs, or rewriting the code just for fun : eliminate duplicated code, unnecessary variables, checkings, etc. So the code size is reduced after the changes, so less code, less bugs
Typical commits, for reducing code size:
https://github.com/gzsombor/ps3mediaser ... 2b7079dd74
https://github.com/gzsombor/ps3mediaser ... 9afbf934d2
https://github.com/gzsombor/ps3mediaser ... 48250dbbeb

I can understand, that it is much more fun, to write a couple of changes, tweaks, and after a new feature is working. But I believe that having a clear code helps everyone else in implementing new features. (For example you do not have to call everywhere PMS.get().getFrame().setReloadable(true), after you've changed one of the configuration values).
Anyway, I still doesn't understand why there are so many forks. Why it's so many different builds ? Why the bug fixes is not incorporated into the main development branch ?

[SubJunk]

The reason for my build is that I'm using a different build of MPlayer/MEncoder to the one in the trunk and it has problems. I anticipated it taking months to fix the problems so I added it to my build instead of blocking PS3MS releases for a few months by committing it to the trunk