As requested and to be more specific, these are some of the things I missed whenever I tried to manage the library from the client side that still can't be done, as far as I'm concerned:
- Configuring Theater View (So I wouldn't have to interrupt the playback and "steal" the display of the HTPC)
- Configuring View Schemes
- Renaming Files (under library tools) after a tagging work is made
- Assigning Cover Art and saving to the file folder
- Deleting Playlists
- Using more than one hosted library
- User Accounts System with permission for viewing and/or editing data, modifying configurations and settings,...
Every single one of those things would be fantastic, obviously. The only ones I have
any concerns about are last two. I'd really like to see them, but I can say as someone who
does use (and helps manage) a multiuser Digital Asset Management system at the office...
The UI to configure those things is
not trivial. That mocked-up dialog box MrHaugen posted is a perfect exemplar. That's a dialog box only a computer science major or open-source geek could appreciate, and it is (IMHO) not appropriate in an application targeted at consumers (certainly high-end, technically adept, "pro-sumers", but consumers all the same, not system administrators only).
That's why I think the best long-term solution would be to eventually roll a separate MC Server Edition product. Without it, MC would still have all the library sharing functions it does now (hopefully with items one through five in your list above checked off). But, if you buy a separate license for (and run) MC Server Edition, it would add a whole new set of functionality:
1. Sharing multiple MC libraries simultaneously.
2. User-based access controls and user account rights management.
3. Server runs as a truly separate process, and uses MC "client" (ANY client) for configuration.
4. Server can run as a process on a headless server much more easily (running at the login window).
5. Metadata conflict resolution workflows.
And, you can think of other possible ways this might "untie their hands" a bit. For example...
What about the configuration of Gizmo, Theater View, WebRemote, and WebPlay functionality? Right now, MC offers the option to modify and configure these systems all independently. That's great, but
man... It takes FOREVER to tweak and get set up correctly if you don't like the defaults much. I just think about someone a little less advanced and dedicated to it than I am (someone who really likes the good quality features of MC, or a "sound guy", or whatever), but just doesn't care to take the time to manage all of that...
I think it would help the "average" user if this were simplified down quite a bit. Say there were only three independent view systems that they have to manage and create: Standard View, Theater View, and Remote. Remote would cover WebRemote, WebPlay, Gizmo, and any other future system that uses the Web Service interface (cough...iOS...cough). On the server version, you'd have the freedom to offer advanced users the opportunity to configure those views separately or with more granularity (or still together if the user prefers). You could even have more than one "Remote" configuration, where different users (or different devices) get served different views depending on their need. Having different views for the DLNA audio-only streamer, verses the one on Gizmo, versus the one on the DLNA TV in the bedroom would be amazing, but it is hard to implement if everyone to has to deal with that stuff!
Whacking the server edition user with User Account Management tasks and the complexities of multiple libraries would be acceptable, but I'm not sure it makes sense in the current "client" version of MC. Just think, with multiple simultaneous library support, an uninformed user could really proceed to screw up his tags royally (if you started serving multiple libraries simultaneously which contained
the same file references, and switched between them accidentally occasionally, it could spell tagging consistency trouble very quickly). A server version could offer these features without suffering the backlash from the more casual users.
And, of course, we'd make it worth their while by paying for an extra license for the trouble.