Breaking changes ? (PMS 2.0 ?)

[taconaut]

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 ?

I've started mlx long before turning orange on the forums, now it could be a branch in the main repository. Btw if anyone would like to contribute, I'd be happy to either add committers on sourceforge or create a branch over here.
If I apply patches, I want to be sure not to break anything. This requires to understand the initial behaviours, the changes and do some testing; this takes some time.

[SharkHunter]

I started my Build basically beacuse chocolateboy asked and there was a need to make the install of PMS+PMSEncoder+Channels etc. simpler. It has then wandered off into the wild with my own really wild features. I doubt anyone wants them into the trunk (and I'm not a dev just a builder and I'm not orange so I have complete freedom to screw things up ) I add stuff that I need, I don't want to spend the limited time I got on this polishing code (that I do at work) here I want to improve and solve problems I got in. I don't want to break anything either (I try hard not to) and the approach is "if it works don't touch".

[renszarv]

Thanks, for the answers My reason for code cleanup is the exact opposite : at work, too much times there aren't enough time to do it properly, only we have time to hack something together, just creating a 'temporary' fix, which will be there for years So, in my free time, I would like to work on a code which doesn't looks ugly And If any of my prospective employer would search for my codes on the internet, I don't want, he find any code which I'm ashamed of. So that's the reason why I like to clean up a couple of things - and because I believe in 'less code, less bugs' mantra And not in the 'it works, so we have to fix it'
So my plan is to continue developing on https://github.com/gzsombor/ps3mediaserver for the previously stated goals, in a more or less prioritized list :
1, code cleanup
2, bug fixes
3, incorporating changes from other forks, and from upstream
4, simple missing features
5, modularization
6, improved remote/headless operation

If anybody has free time, and want to help, just fork my repo - or fork lightglich's repo - to cooperate

Of course, I hope these change will end up, in one day, in the official PMS too

[Raptor399]

I just arrived back home from a long holiday, and although I didn't feel like diving into the discussion from my iPhone on the beach, my fingers were itching to dive into this discussion. Sorry for being late to it! A lot of good remarks were made, I'll try not to reiterate them.

From my perspective, the main issues raised in this thread are:

1) PMS architecture
2) SVN vs. Git

Ad 1):
I'm really missing The Big Picture. Currently, PMS is as is. Sure it has bugs, but it works and the code is its own documentation.
Sounds fine, but for me as a programmer that is really suffocating to not be able to extend something knowing things won't topple on the other side of the application. This whole concept of "Breaking Change" scares the crap out of me!

I think PMS should put its foot down more visibly. "*This* is PMS, *this* is what it wants to do, *this* is how it does it and *this* is what you can do to make PMS dance to your plugin." Well, something like that.
One of the first things we should do is to freeze and expose PMS's API interface. This will allow people to shuffle code in the implementation as they see fit, without breaking anything. And second we should document better, as in "why does the code what it does?"

From there on, bugs can be fixed and features can be added at will. The API can even be expanded or (breaking though!) changed.

Ad 2):
We should make up our minds on which one to support: SVN or Git.

As you have noticed, we have been working on a Mavenized version of PMS to get some experience in the matter (I was away, so I haven't kept it in sync). My personal opinion is that - given the number of custom builds and the community's need to patch - Git would definitely fit the community nicely. And Maven would simplify maintenance a lot as well (just check the number of file commits needed for an official release for example).

I think we should make up our minds, and then push for whatever we choose. In Git/Maven's case by setting a version and a date at which it will be released. Otherwise we're never going to take the plunge into the deep.


For now, it would be nice if you could wait out the verdict on this one. I find that keeping track of different sources in SVN and Git is quite a hassle and once you start rewriting and working on from that, it will only get worse. If we choose to go the Git route, it will be wiser to fork from there - once we've set it up properly. From the patches that I saw (on my iPhone ) you submit nice code with nice to haves for PMS.

[renszarv]

Sorry for the late answers, I'm better in coding than writing long messages At least, I hope so

I'm really missing The Big Picture. Currently, PMS is as is. Sure it has bugs, but it works and the code is its own documentation.
Sounds fine, but for me as a programmer that is really suffocating to not be able to extend something knowing things won't topple on the other side of the application. This whole concept of "Breaking Change" scares the crap out of me!

I don't want to break anything, from the user point of view, that's for sure This 'breaking changes' question is just come up for me, because I've opened a couple of tickets at googlecode for various code cleanup tasks, and attached a patches to solve it (1189 and 1210 the tickets), which marked as 'breaking changes'. I can understand that just before a release, there wont be a wise decision to merge API changing modifications. So I would like to know, is there any interest merging them, if yes, when, and how can I help it. As I have a yet another 10 or more patches, for other code cleanups, and a couple of features waiting to be submitted And in the end, pms is extensible in a way, that pms-mlx is just a plugin it. I'm not there yet, but it's close now

I think PMS should put its foot down more visibly. "*This* is PMS, *this* is what it wants to do, *this* is how it does it and *this* is what you can do to make PMS dance to your plugin." Well, something like that.
One of the first things we should do is to freeze and expose PMS's API interface. This will allow people to shuffle code in the implementation as they see fit, without breaking anything. And second we should document better, as in "why does the code what it does?"

From there on, bugs can be fixed and features can be added at will. The API can even be expanded or (breaking though!) changed.

Ad 2):
We should make up our minds on which one to support: SVN or Git.

As you have noticed, we have been working on a Mavenized version of PMS to get some experience in the matter (I was away, so I haven't kept it in sync). My personal opinion is that - given the number of custom builds and the community's need to patch - Git would definitely fit the community nicely. And Maven would simplify maintenance a lot as well (just check the number of file commits needed for an official release for example).

I think we should make up our minds, and then push for whatever we choose. In Git/Maven's case by setting a version and a date at which it will be released. Otherwise we're never going to take the plunge into the deep.


For now, it would be nice if you could wait out the verdict on this one. I find that keeping track of different sources in SVN and Git is quite a hassle and once you start rewriting and working on from that, it will only get worse. If we choose to go the Git route, it will be wiser to fork from there - once we've set it up properly. From the patches that I saw (on my iPhone ) you submit nice code with nice to haves for PMS.

I generally agree with you. Unfortunately the code is a little bit too interconnected, and after a couple of tries to separate the UI from the internal engine, and datamodel I've temporaly postponed this task in my to-do queue Creating one maven project from the whole pms project is not soo difficult, I think, but I'm happy that it's already tried, and succeeded
I know that keeping track of different sources in SVN and Git is problematic, as I already trying to follow the 'upstream' the 'pms-mlx' and the 'subjunk' branches - apologises for the other forks, missing them - and it's a pain. So git or svn ? how it will be decided? Of course I prefer git (or some other non-centralized VCS) Or I would like to have commit right If it's not convincing argument against svn, I don't know what could be

[taconaut]

And in the end, pms is extensible in a way, that pms-mlx is just a plugin it. I'm not there yet, but it's close now

Cool, I had been thinking about that myself, but have chosen the quick'n'easy way (e.g. with not plugging an interface in front of RootFolder, but duplicating it with another behaviour in another package). I guess you've seen the wiki page mentioning the changes to the base code!?

I'm going to seize the opportunity to welcome you to the pms commiters (just in case noone told you you were one since last week )

[renszarv]

And in the end, pms is extensible in a way, that pms-mlx is just a plugin it. I'm not there yet, but it's close now

Cool, I had been thinking about that myself, but have chosen the quick'n'easy way (e.g. with not plugging an interface in front of RootFolder, but duplicating it with another behaviour in another package). I guess you've seen the wiki page mentioning the changes to the base code!?

I'm going to seize the opportunity to welcome you to the pms commiters (just in case noone told you you were one since last week )

Ups, I haven't seen that wiki page But it confirms for me, that I've found every relevant difference between pms-mlx and pms And yes, I've wondered why there is a separate RootFolder. This was the original diff, which I've gone through, it's not the latest, but hope not too much changed since. Currently the 'external plugins' of pms-mlx is not integrated yet, but I will work on that too, in this branch

Thanks, for your welcoming, I'm very happy being on board

[taconaut]

As I had started this branch long before becoming a commiter, it was important for me to have as few changes as possible in the original code. That's why there is a second plugin system behaving quite similarly to the original one and some other design choices. There are lots of things which could be improved when they mlx gets merged into pms. E.g. for every video shown on the renderer a new RealFile is being created; it would be a lot nicer (and improve memory consumption) if we could always use the same object to stream the video but still be able to set a custom thumbnail and file name for the different instances.

There haven't been many changes compared to the version you're on. A notable one is r43 where the way the file parsing is being configured has been changed (that's the change requiring to move the initialization of the renderers before the media library initialization).