RE: [slim] Re: Multiple Profiles?
> > well, I think I'm just getting the impression that demands for how this > must > work will end up causing the one instance to double up on so much already. > Its > a given that once such a feature is created, there will be a user out > there who > will demand that it works in every different way possible. Share some > files, > not others, share prefs, not others. User defined access to players, > swappable > on the fly, admin lockouts etc. Just about any feature you name will have > at > least one person who will say that its absolutely required. The idea of > two > separate servers just cuts to the chase, though admittedly bars shared > libraries on the fly. You'd have to use symlinks. > They have already got their own custom network transport why not just expand on it and create the SOS(Slim Operating System) and SFS(Slim File System). It would probably be easier in the long run;) The information contained in this e-mail is strictly confidential and for the intended use of the addressee only; it may also be legally privileged and/or price sensitive. Notice is hereby given that any disclosure, use or copying of the information by anyone other than the intended recipient is prohibited and may be illegal. If you have received this message in error, please notify the sender immediately by return e-mail. All e-mail sent to this address will be received by Acacia Pacific Holding's e-mail system and is subjected to archiving and review by someone other than the recipient. Acacia Pacific Holdings has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. We accept no liability for any damage sustained as a result of software viruses and advise you carry out your own virus checks before opening any attachment. ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Multiple Profiles?
Quoting ron thigpen <[EMAIL PROTECTED]>: > also, wouldn't this increase overhead for system resources to load > multiple instances of all the server bits? well, I think I'm just getting the impression that demands for how this must work will end up causing the one instance to double up on so much already. Its a given that once such a feature is created, there will be a user out there who will demand that it works in every different way possible. Share some files, not others, share prefs, not others. User defined access to players, swappable on the fly, admin lockouts etc. Just about any feature you name will have at least one person who will say that its absolutely required. The idea of two separate servers just cuts to the chase, though admittedly bars shared libraries on the fly. You'd have to use symlinks. > i'm thinking of multiple libraries all being in the same database, just > with tracks having a reference to the library that they belong to. it all depends on how much isolation is required to satisfy the majority of users. It may be enough to simply obey user permissions on a per-directory basis. A bit complicated on systems that dont really have very good multi-user permission control. > in my mind, it's more like building in a new upper level bit of metadata > (like "genre") and then building the UI to support this structure. most > functions could work exactly as they do now, except that calls to the > track database would have an extra WHERE clause for library filtering. > > server settings would be common to all users but with limited access to > administration i think that's probably ok. and per-player settings are > already supported. I agree in principle. I think I'm just gunshy after hacking my way through a miserable attempt to handle multiple folders (bug 607). Just trying to make snse of that was headache enough to keep me from pondering any effort on my part on the code for this kind of change. > right-o on the one machine preference (or zero, truth be known). no > reason why each library couldn't be hosted centrally and share one SS > instance. some libraries could be expected to go offline and online > (laptop, portable drive or player). server would have to detect this, > but previous scans could be preserved in the DB if the device/path were > uniquely recognized. true enough. part of my thinking was also influence by the current server limit on db access. sqlite can't handle concurrent connections, so a single db is a thing of the future. Right now, this discussion has no timeline, so my main angle was something near term. eventually mySQL use will allow this kind of thing. > ok. glad to know i'm (we're) not making you crazy. i don't know that > my vision of how this would work is the best, but it does seem possible. > and i am willing to wait for a really kickass implementation. > > oh, willing to work within the limits of my time and capabilities. good to know. I'm not fully into this side of things myself. A lot of the db stuff is out of my league. In the interest of disclosure, I think my personal motive is avoiding a monstrously complex beast that is trying too hard to give everything to specific individuals and spreading too thinly on the core design requirements. Of course, I don't know exactly what those are, so I tsick with my own sense of confusion as a limit. It was a full-time job keeping on top of all the activity. Since I already have a full-time job, I gave up on keeping up with every path. :) -kdf -kdf ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Multiple Profiles?
fuzzyT Wrote: > i'm thinking of multiple libraries all being in the same database, just > > with tracks having a reference to the library that they belong to. > > > Trying to refactor the existing server to run multiple libraries > concurrently > > would probably end up being very similar to running multiple copies > of the > > whole server. > > in my mind, it's more like building in a new upper level bit of > metadata > (like "genre") and then building the UI to support this structure. > most > functions could work exactly as they do now, except that calls to the > track database would have an extra WHERE clause for library filtering. > > server settings would be common to all users but with limited access to > > administration i think that's probably ok. and per-player settings are > > already supported. > I see the use of multiple libraries similarly, but as a kind of half-step toward user profiles. My suggestion is that implementing multiple libraries would satisfy the majority of the reasons that people ask for user profiles. The login, user interface prefs and scanning prefs aren't as critical, but need to happen some day. > and if you don't want to get hung up in tying it together with security, > > then just consider library filtering to be a pref and let users choose > > which to see. > >From what I've read in the requests the security aspect is an important part of the need for separate users/libraries. You don't want the kids getting into the adult comedy albums, or you're having a party and you want to restrict what music the guests may play. Perhaps implement the ability to lock a particular Squeeebox into a single libary from a password protected server setup. -- JJZolx Jim ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Multiple Profiles?
kdf wrote: The server does already make use of the HOME environment for users in some OSes. If the server were tweaked a bit to allow it to easily run as multiple servers, the user profile slimply becomes a matter of running the server under a different user, with associated prefs, library, db, etc. i don't think this would allow for users to access more than one library in a blended mode. also, wouldn't this increase overhead for system resources to load multiple instances of all the server bits? i'm thinking of multiple libraries all being in the same database, just with tracks having a reference to the library that they belong to. Trying to refactor the existing server to run multiple libraries concurrently would probably end up being very similar to running multiple copies of the whole server. in my mind, it's more like building in a new upper level bit of metadata (like "genre") and then building the UI to support this structure. most functions could work exactly as they do now, except that calls to the track database would have an extra WHERE clause for library filtering. server settings would be common to all users but with limited access to administration i think that's probably ok. and per-player settings are already supported. and if you don't want to get hung up in tying it together with security, then just consider library filtering to be a pref and let users choose which to see. This can be done right now by simply using multiple pc's, so it seems to me that this is really the core issue. users want to have to only use the one machine. If this extends to insisting on ONE application, perhaps a wrapper then. right-o on the one machine preference (or zero, truth be known). no reason why each library couldn't be hosted centrally and share one SS instance. some libraries could be expected to go offline and online (laptop, portable drive or player). server would have to detect this, but previous scans could be preserved in the DB if the device/path were uniquely recognized. All the discussion so far is great, and keep it up. I just thought I'd toss in what seemed to be as simple as psosible for the approach. It would have the advantage of less waiting for it to become a reality. ok. glad to know i'm (we're) not making you crazy. i don't know that my vision of how this would work is the best, but it does seem possible. and i am willing to wait for a really kickass implementation. oh, willing to work within the limits of my time and capabilities. --rt ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Multiple Profiles?
The server does already make use of the HOME environment for users in some OSes. If the server were tweaked a bit to allow it to easily run as multiple servers, the user profile slimply becomes a matter of running the server under a different user, with associated prefs, library, db, etc. You can then use existing plugins to block setup, etc. The SB2 can already be told which server to use; likely just needs a bit more to allow selection of the port in order to chose which of the servers on a given pc. Trying to refactor the existing server to run multiple libraries concurrently would probably end up being very similar to running multiple copies of the whole server. This can be done right now by simply using multiple pc's, so it seems to me that this is really the core issue. users want to have to only use the one machine. If this extends to insisting on ONE application, perhaps a wrapper then. All the discussion so far is great, and keep it up. I just thought I'd toss in what seemed to be as simple as psosible for the approach. It would have the advantage of less waiting for it to become a reality. -kdf ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Multiple Profiles?
JJZolx wrote: But the idea of multiple libraries is something that wouldn't have to depend on user profiles. It might be a browse level above Browse Music. true, it doesn't have to depend on user profile, but it helps. some of the user issues that were driving the requests for multiple libraries would be automatically solved if libraries were attached to users. i'm thinking of the kids music polluting the parent's library, adult themed music being accessible to kids, roommates who don't want to expose their libraries to each other. i guess in my mind the concept of library has more to do with ownership and management responsibility than anything else. it's /personal/, kind of like the data on your iPod, cellphone or PDA. given this, the idea of having your own music directory makes sense. OS-level rights to that directory can easily exist. differences in tagging and format preferences can be honored. and segregation in the web interface where playlists and favorites can be managed also seems to make sense. although libraries could be useful for genre segregation we already have mechanisms for that. The question I'd have is how do you designate what is contained within a given library? Setting different music library root folders is one way, but would require quite a bit of creative use of links/shortcuts unless you accepted having multiple copies of a track in each library to which it belongs. overlap may well occur, but could be managed a number of ways. as you point out, rather than a copy being placed in more than one library aliases could be used. as long as SS was adept at recognizing and dealing with these it shouldn't pose a problem. alternatively the duplicates (and near duplicates) could either be presented distinctly or merged in the UI by some sort of rule. One approach I could see is having a "master" library with a single music folder like there is now, then creating a web interface where you could build a library by browsing the music directory and saying "Add to Library". This might also make (re)scanning easier, although when doing a scan you'd have to maintain library db links so that work done to create the custom libraries aren't lost. the problem of persisting the library-to-track association on rescan and wipes is one thing that got my thinking headed in the direction of directory based libraries. --rt ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Multiple Profiles?
User profiles strike me as a feature that must happen at some point in time. But the idea of multiple libraries is something that wouldn't have to depend on user profiles. It might be a browse level above Browse Music. The question I'd have is how do you designate what is contained within a given library? Setting different music library root folders is one way, but would require quite a bit of creative use of links/shortcuts unless you accepted having multiple copies of a track in each library to which it belongs. One approach I could see is having a "master" library with a single music folder like there is now, then creating a web interface where you could build a library by browsing the music directory and saying "Add to Library". This might also make (re)scanning easier, although when doing a scan you'd have to maintain library db links so that work done to create the custom libraries aren't lost. -- JJZolx Jim ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Multiple Profiles?
Randall wrote: kdf Wrote: were you asking for ideas, or merely giving orders? if it's the latter, you can take a number... http://bugs.slimdevices.com/show_bug.cgi?id=825 -kdf He ordered me first! I did not see the issue until you explained the user/squeezebox control problem. I think segmenting your music by access control and then pointing different squeezeboxes at different root directories that contain the links to the different music by roles is the only solution I see. I also think that the playlist/party mode plugin (that restricts admin privs) is a solution. Not pretty, but doable. This of course still implies build access control subdirectories and stuff, so DO THAT WORK :)! ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Multiple Profiles?
On Aug 11, 2005, at 7:34 AM, Randall wrote: kdf Wrote: were you asking for ideas, or merely giving orders? if it's the latter, you can take a number... http://bugs.slimdevices.com/show_bug.cgi?id=825 -kdf He ordered me first! Now, boys, I don't care who started it. Don't make me pull this car over! ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Multiple Profiles?
kdf Wrote: > > > were you asking for ideas, or merely giving orders? if it's the latter, > > you can take a number... > http://bugs.slimdevices.com/show_bug.cgi?id=825 > -kdf He ordered me first! -- Randall ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Multiple Profiles?
I don't know about the whole profiles thing, maybe that's overkill. But I would like a way of segmenting the music library. Particularly I would like a way of limiting the choice that the random plugin could make, but I guess that's one for the 3rd party forum. Cheers, Bruce. -- Bruce Hartley ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Multiple Profiles?
On 10-Aug-05, at 8:49 PM, Randall wrote: Michael Amster Wrote: Randall wrote: Howdy dev team. Question. I'd like to see the squeezebox allow different profiles. Why not? For example. Say I personally have 50% decent songs while the other 50% are songs that have explicit lyrics in which I really wouldn't want others to hear during a party. If I could turn on the squeezebox and choose a profile that can only see the half of the library that I wouldn't mind my mother hearing - that would be awesome. Please Slimserver dev team, PIMP my Squeezebox! Any ideas? Randall Build playlists... No... Build Profiles. were you asking for ideas, or merely giving orders? if it's the latter, you can take a number... http://bugs.slimdevices.com/show_bug.cgi?id=825 -kdf ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Multiple Profiles?
Michael Amster Wrote: > Randall wrote: > > >Howdy dev team. Question. I'd like to see the squeezebox allow > >different profiles. Why not? For example. Say I personally have > 50% > >decent songs while the other 50% are songs that have explicit lyrics > in > >which I really wouldn't want others to hear during a party. > > > >If I could turn on the squeezebox and choose a profile that can only > >see the half of the library that I wouldn't mind my mother hearing - > >that would be awesome. > > > >Please Slimserver dev team, PIMP my Squeezebox! > > > >Any ideas? > > > >Randall > > > > > > > > > Build playlists... No... Build Profiles. I have 6 squeezeboxes in the house. I have 4 people with access to them at all times. I'm sure I'm not the only one that wants to control the devices this way. Would you let someone other than yourself log into your computer as yourself to browse around and see what they can find? -- Randall ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
