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
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss

Reply via email to