Normal
I think that application design is partly based on what one would use oneself, and partly on how one thinks other people would use it. In the case of the watched threshhold, I think that the original designers of MP provided that for use with the "clean-up" action, where one of the choices is "delete all watched recordings". With pre-padding and post-padding on recordings, a fully-watched programme is never going to be 100% of the recording, but of course the exact amount that represents fully-watched will depend on how much pre-padding and post-padding the user has specified.I don't always watch a recording in one sitting, and I find it helpful to have an indication of which recordings I have started watching -- hence my use of a low watched-threshhold of 5%. But the consequence of this choice is that I can never use the "delete all watched recordings" action, because it will delete the partially watched recordings too. The original MP designers probably did not anticipate my use of watched threshhold, but that does not invalidate my use --- it just means that the original designers don't always think of everything.In an open-source application staffed by volunteers, it is inevitable that developers will join and later depart the development team, and the knowledge of why a particular feature was implemented in a particular way departs with them. Us Johnny-come-latelies then have to try to work out why some feature behaves the way that it does, and decide whether that behaviour was intentional or an accident. Although we may not be able currently to think of the intended use case, we need to be very careful about making an incomptible change. Improving the implementation in a way that does not change the externals is fine, but making incompatible changes to the externals requires great care, otherwise we risk annoying existing users who value the existing behaviour.I have never done any database programming. and I have no doubt that creating an optimal database design requires considerable expertise. It looks like we now have a contributor who has that expertise. But we need to be sure that the benefits of the improved design do not remove or alter features that users value.I would be prepared to trial your new implementation, but although I am a "tester", I use none of the extensions that [USER=68833]@ajs[/USER] has been concerned about, and have only a single-seat installation, so my testing would be very "one-dimensional".-- from CyberSimian in the UK
I think that application design is partly based on what one would use oneself, and partly on how one thinks other people would use it. In the case of the watched threshhold, I think that the original designers of MP provided that for use with the "clean-up" action, where one of the choices is "delete all watched recordings". With pre-padding and post-padding on recordings, a fully-watched programme is never going to be 100% of the recording, but of course the exact amount that represents fully-watched will depend on how much pre-padding and post-padding the user has specified.
I don't always watch a recording in one sitting, and I find it helpful to have an indication of which recordings I have started watching -- hence my use of a low watched-threshhold of 5%. But the consequence of this choice is that I can never use the "delete all watched recordings" action, because it will delete the partially watched recordings too. The original MP designers probably did not anticipate my use of watched threshhold, but that does not invalidate my use --- it just means that the original designers don't always think of everything.
In an open-source application staffed by volunteers, it is inevitable that developers will join and later depart the development team, and the knowledge of why a particular feature was implemented in a particular way departs with them. Us Johnny-come-latelies then have to try to work out why some feature behaves the way that it does, and decide whether that behaviour was intentional or an accident. Although we may not be able currently to think of the intended use case, we need to be very careful about making an incomptible change. Improving the implementation in a way that does not change the externals is fine, but making incompatible changes to the externals requires great care, otherwise we risk annoying existing users who value the existing behaviour.
I have never done any database programming. and I have no doubt that creating an optimal database design requires considerable expertise. It looks like we now have a contributor who has that expertise.
But we need to be sure that the benefits of the improved design do not remove or alter features that users value.
I would be prepared to trial your new implementation, but although I am a "tester", I use none of the extensions that [USER=68833]@ajs[/USER] has been concerned about, and have only a single-seat installation, so my testing would be very "one-dimensional".
-- from CyberSimian in the UK
