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