If you're talking about some other aspect of security in a networked system, then it's something that should be dealt with using the security features of the operating system. It's not relevant to the topic. And even in the far-fetched scenario where you've given someone you don't trust access to your network and your MC Library, there's not much point in quibbling a simple library-based access control system might not be as effective as a much more complicated multi-user MC would. Surely we're all better off with something that's easy to implement (because we might actually get it), easy to use, and which is potentially useful to everyone—even those who think they need something more sophisticated.
You're partially right. In a perfect world, access to your media should be done through the OS security layers. The problem here is that you don't use library server (as you say your self), and that might be part of why you don't see the limitations. The technical problems with using Library server and restricting access on shares and NTFS, is that MC uses the access settings purely for the user logged on in the session MC is running. So, it would be impossible to use Library server and the OS limitations for more than one person/group/computer. IF MC library was smart enough to get the credentials from the client and use the media files depending on this access control lists (Share and NTFS), then we could do almost anything with the access rules. The problem would however still be that multiple users could use the same computer and logged in user. I think it's a fair bet that many HTPC users have one common user on the HTPC, and they might not even shut down the computer properly. Just using Sleep or Hibernate instead. So, the security rules is not super smooth to relay on. However, if you could connect your proposed access "modes" to user/group rights on the share/ntfs volume, then you might have a workable solution.
When you don't use Library servers, it's also hard to see the advantages with this system. If you have lot's of media that several users access on several computers, there are imo huge benefits with tagging and organizing on one central location only. And this is where many new houses and apartments are heading towards. Easily accessible media in most rooms. I would be willing to bet a good amount of money that more people would like to use this instead of multiple local libraries if they just had the know-how. This touches the user friendliness subject again, and I would happily donate money to the guy/girl that gives us some how-to videos
That's another discussion though.
You say again that user based library is something that would probably not be used in most cases. At this day you are probably right. But if it was easy to enable and use, I think that many more would like to use it if it was available. If we had removed some of the few remaining obstacles in the Server/client mode, I think that many more users would like to even run Library server and user based library. The obstacles I'm talking about here is for example the problem with importing from clients to the server and allowing file level manipulation on server (media and cover art). This will hopefully be fixed in time. I think that the market for this is much higher than many here anticipates.
Such a system could be used locally on one client, or through a library server. I can think of many cases other than my "house owner and tenant" case as very valid examples of why this is important. Here's a few:
- If I had a 16 year old son, he would probably be watching lot's of other things than me.
- If I had kids, they would watch children stuff. I do not need stats for that.
- If you have a flexible wife, she might have her own shows, while you watch your shows in another room.
- You have guests that want access to changing music on the bathroom, but you would not want them to play a video and occupying the toilet for a long time
I KNOW this is not the essence of this discussion, but it's all connected. At least in my head. I'll get back to why later on.
Access ModesI've said it before, and I'll say it again.. I have nothing against your suggestion of modes of access. You could expand the current access rules and party lock down a bit, and tie it to password protected "modes" with a sort of child parent system so you can access more restricted modes easily, but more open restrictions would require a password. Perhaps throw in option to remove the exit item in Theater View as well. I think that was what you suggested(?), and I really like that. It sounds great! You could even throw in who can see what views and so on, so it's much more personalized for the person or group of persons that wants to use the media. That would be the frosting on the cake.
EnforcementI think that the only correct way of getting this is through the library. So, if you use a local client you only have the access rules for this client. If you set this on the library server, all the access control settings are forced from the server to the clients. That way, you would have this system on all clients, and the users could only use their mode, no matter what (ok, you have the hacking part as well, but let's not take it to far in the start).
This would be enough for a while. Even for me. But let's take it ONE step further and see what else could be done.
Multi userYou might think: "Oh, Jeeeesus. Why do he talk about this again?". I'll try to explain. The system you described Rick, is not much different from a User access setup. You call it modes, but you could easily call it users or groups instead. Sure, it does not involve multi user stats, but that could be tied to this at a
later stage when people finally realize the power of it. Let me throw out one example.
So, I have some thoughts and questions regarding this subject....
What would really be needed for a Multi User database? It would require adding more fields, but this could be hidden for all except the user is self. And perhaps the master user for the library. Hence not complicating things for the actual users. Only the library admin if he chooses to use it this way. Let's take one important library field to start with: Number Plays. This one could have a shown name of Number Plays for the user, but could have a internal name of "Number Plays Mode/UserName". So, the view rules you would create for the users could easily be set with each mode or person/groups name. The library server would sync this changes just as todays changes. If users (not the master) create views them self, the MC engine might be able to replace rules with for example "Number Plays" with "Number Plays Junior" automatically, so there's no noticeable change for the user.
How much trouble would this really be? At least for me, it does not look like a HUGE undertaking (but again, I'm no programmer and have very little knowledge of how MC is built). Dynamically added fields for Users/groups, syncing those fields and some logic how to parse user based library fields to your own set of fields. There might be several things I'm not taking into considerations here, but I can't think of any big hindrances right now.
